A method for processing blue-ray storage customer acceptance data

Abstract

The present application relates to the field of data processing technology of blue-ray storage media delivery, and especially relates to a kind of blue-ray storage customer acceptance data processing method.The method obtains delivery list, disc box identification code, file metadata and burning archive record, associates delivery task identification and version, generates acceptance task record, and forms expected disc box and file set and measured disc box and file set;Compare corresponding set, generate difference record and abnormal object range, perform consistency verification on delivery file and generate traceability state;According to the above results, obtain acceptance conclusion, form current effective delivery relationship when success, generate rollback task when failure;According to the execution receipt, the original delivery relationship is invalidated, and a replacement relationship record and a state version are generated, and the current effective delivery relationship is updated based on the updated object re-inspection.The present application continuously associates abnormal range, rollback task, relationship invalidation and version re-inspection, effectively improves the accuracy of abnormal positioning and version traceability.

Description

Technical Field

[0001] This invention relates to the field of Blu-ray storage media delivery data processing technology, and in particular to a Blu-ray storage customer acceptance data processing method. Background Technology

[0002] In the field of Blu-ray storage media delivery data processing, existing solutions typically obtain the delivery list, cartridge identification code, and file metadata after the Blu-ray media has completed file writing. They then verify the number of cartridges, files, file versions, file sizes, and file summaries according to preset acceptance rules. Some solutions also query burning records, post-write verification records, and archive logs based on the Blu-ray media identification to generate acceptance conclusions, acceptance reports, or anomaly records. While these solutions can perform basic verification of delivered files, when a delivery task includes multiple cartridges, and each cartridge contains multiple delivered files, cartridge-level data and file-level data are usually recorded separately, making it difficult to distinguish between missing cartridges, missing files, duplicate files, and files belonging to the wrong cartridge.

[0003] Existing solutions often employ a fixed process of comparing the delivery list with the actual file records item by item, or querying the corresponding burning log based on a single disc tray identifier. When files are re-burned, disc trays are replaced, or the delivery list is supplemented, the correspondence between the original file version, the original disc tray identifier, and the updated object changes. Existing processing procedures often only update abnormal states or re-execute acceptance, making it difficult to limit the rollback objects based on the level of the abnormal object, and also difficult to distinguish between the original file version relationship and the original disc tray relationship that should be invalidated. This can easily lead to situations where the original delivery relationship and the updated delivery relationship are both in a valid state at the same time.

[0004] For the joint processing of delivery lists, cartridge identifiers, file metadata, burning records, post-write verification records, and archive logs, existing technologies still lack continuous data connections between the formation of the scope of abnormal objects, the limitation of rollback task objects, the updating of the original delivery relationship status, and the re-verification of updated objects. Therefore, it is necessary to address the issue of how to limit the rollback scope based on the differences between cartridge and file levels, and how to establish a current valid delivery relationship through version verification after the original delivery relationship has become invalid, all within the framework of Blu-ray media delivery and acceptance. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides a method for processing Blu-ray storage customer acceptance data, comprising:

[0006] S100: Obtain the delivery list, disk tray identifier, file metadata, burning record, post-write verification record, archive log, and acceptance rule record; associate and bind the delivery task identifier, list version, file version, and rule version to generate an acceptance task record; generate the expected disk tray set and expected file set based on the delivery list, and generate the actual disk tray set and actual file set based on the disk tray identifier and file metadata;

[0007] S200: Compare the expected disk cartridge set and the actual disk cartridge set, and compare the expected file set and the actual file set of the corresponding disk cartridge to generate difference records and abnormal object ranges; perform consistency verification on the corresponding delivery files; generate traceability status based on the burning records, post-write verification records and archive logs;

[0008] S300. Obtain the acceptance conclusion based on the difference record, consistency status, and traceability status; when the acceptance is successful, generate an association record and mark it as the current valid delivery relationship; when the acceptance fails, generate a rollback task, and the rollback task records the scope of the abnormal object.

[0009] S400: Receive the execution receipt of the rollback task; set the original delivery relationship to an invalid state according to the rollback task identifier, generate a replacement relationship record and update the state version; re-execute S200 based on the updated object, and update the current valid delivery relationship when the re-verification is successful.

[0010] Furthermore, the acceptance task record includes acceptance task identifier, delivery task identifier, delivery number, delivery batch, list version, document version, rule version, and status version;

[0011] Obtain the acceptance task record with the same delivery task identifier;

[0012] Idempotent processing is performed based on the data summary and status version; the rule version associated with the acceptance task record remains unchanged during the acceptance period.

[0013] Further, the expected disk set and expected file set are generated based on the delivery list, including:

[0014] Based on the field mapping relationship, extract the delivery order number, disk identification code, file metadata, file version and file summary from the delivery list to generate standard delivery field records;

[0015] Generate the desired disk box set based on the multiple disk box identifier codes recorded in the standard delivery field record;

[0016] Establish a correspondence between the metadata of files with the same disk tray identifier and the corresponding desired disk tray, and generate a set of desired files.

[0017] Further, the measured disk cartridge set and measured file set are generated based on the disk cartridge identifier and file metadata, including:

[0018] A set of actual disk cartridges is generated based on the read disk cartridge identification codes;

[0019] Read the file metadata corresponding to each disc cartridge based on the Blu-ray media identifier;

[0020] The file metadata is associated with the corresponding test disk cartridges to generate a set of test files.

[0021] Further, generating the difference records and the range of anomalous objects includes:

[0022] Compare the expected disk box set with the actual disk box set to generate missing object records, redundant object records, and duplicate object records corresponding to the disk boxes;

[0023] Compare the expected file set and the actual file set of the corresponding disk compartment, and generate missing object records, redundant object records and duplicate object records corresponding to the delivery file;

[0024] When the disk compartment identifier code in the file metadata record is inconsistent with the disk compartment identifier code in the standard delivery field record, the corresponding delivery file will be written into the difference record.

[0025] An anomaly object range is generated based on the disk identification code and file metadata in the difference record.

[0026] Furthermore, the consistency verification includes:

[0027] For delivered files in the expected file set and the actual file set that have the same file metadata and the same disk identification code, compare the file version, file size and file digest.

[0028] When the file version, file size, and file digest are all consistent, the consistency status is marked as valid.

[0029] If one of them is inconsistent, a field difference record is generated, and the consistency status is marked as invalid.

[0030] Further, the traceability status is generated based on the burning records, post-write verification records, and archived logs, including:

[0031] Search for Blu-ray media identification based on the disc tray identification code;

[0032] Based on the Blu-ray media identifier and file metadata, query the burning record, write result record, post-write verification record, and archive log;

[0033] Retrieve the source record identifier, file version, status version, and timestamp for each record;

[0034] When each record meets the version matching condition, the status validity condition, and the time sequence condition, the traceability status is marked as a valid status;

[0035] If there are missing records, version mismatches, invalid states, or inconsistent time sequences, the traceability status will be marked as invalid.

[0036] Furthermore, acceptance is considered successful if there are no missing object records, redundant object records, or duplicate object records in the difference records, and both the consistency status and the traceability status are valid.

[0037] Upon successful acceptance, the associated records include the delivery task identifier, delivery order number, disk identification code, file metadata, file version, rule version, status version, and source record identifier.

[0038] Record the aforementioned relationship in the acceptance log.

[0039] Furthermore, in the event of acceptance failure, the rollback task is generated according to the rollback action mapping relationship, including:

[0040] A supplementary submission task is generated when there are unextracted fields in the required field set.

[0041] An exception is defined as a delivered file, and a re-creation task is generated when there are missing files, inconsistent file versions, inconsistent file digests, or invalid post-write verification records.

[0042] An abnormal object is a disk cartridge, and a cartridge replacement task is generated when there is an abnormal disk cartridge identifier, an unrecognizable Blu-ray media identifier, or multiple post-write verification records of delivery files are invalid.

[0043] The rollback task record includes the rollback task identifier, the scope of the abnormal object, the processing action, the original object version, the completion conditions, and the task status.

[0044] Furthermore, the execution receipt includes a rollback task identifier, processing action, original object version, updated object identifier, updated object version, and task status;

[0045] When the processing action is to re-copy, the association record corresponding to the original file version is set to an invalid state;

[0046] The processing action is to set the association record corresponding to the original disc cartridge identification code to an invalid state when the cartridge is replaced;

[0047] Write the original object version, the updated object version, the rollback task identifier, and the timestamp into the replacement relationship record and update the status version;

[0048] Re-execute S200 based on the updated object;

[0049] When the re-verification passes, the association record corresponding to the updated object is marked as the current valid delivery relationship. When the re-verification fails, a rollback task is generated based on the scope of abnormal objects corresponding to the re-verification result.

[0050] Write the execution receipt, replacement relationship record, and re-verification results into the acceptance log.

[0051] The following are its main beneficial effects:

[0052] (1) To address the problem of difficulty in distinguishing the level of anomalies when multiple disks and multiple delivery documents are recorded separately, the disk-level difference and the file-level difference are formed by continuous comparison of the disk set and the corresponding file set, and the case where the file exists but the disk to which it belongs is inconsistent is distinguished from the case where the file is missing; the scope of anomalies formed by the difference records can clearly identify the disk or delivery document corresponding to the subsequent rollback task.

[0053] (2) To address the problem that it is difficult to confirm the current file version source status by querying only a single burning log, the consistency verification of file version, file size and file summary, as well as the comparison of version, status and time order between burning records, write result records, post-write verification records and archive logs, form a traceability status corresponding to the current file version to be accepted, so as to avoid historical version records, invalid records or abnormal order records being used as the current acceptance basis.

[0054] (3) To address the issue of discontinuous connection between the original delivery relationship and the updated delivery relationship after file re-copying or disk replacement, the invalid objects of the original delivery relationship are limited by the rollback task identifier, and the correspondence between the original object and the updated object is retained by the replacement relationship record; the updated object is marked as the current valid delivery relationship after the re-verification is passed, so that the current valid version in the acceptance log corresponds to the actual disk and file version to be delivered. Attached Figure Description

[0055] Figure 1 A flowchart illustrating a Blu-ray storage customer acceptance data processing method provided in this application embodiment;

[0056] Figure 2 This is a structural block diagram of a Blu-ray storage customer acceptance data processing method provided in an embodiment of this application. Detailed Implementation

[0057] Example 1: Refer to Figure 1 This is a flowchart illustrating a Blu-ray storage customer acceptance data processing method according to an embodiment of the present invention. The process may include at least steps S100-S400:

[0058] S100: Obtain the delivery list, disk tray identifier, file metadata, burning record, post-write verification record, archive log, and acceptance rule record; associate and bind the delivery task identifier, list version, file version, and rule version to generate an acceptance task record; generate the expected disk tray set and expected file set based on the delivery list, and generate the actual disk tray set and actual file set based on the disk tray identifier and file metadata;

[0059] S200: Compare the expected disk cartridge set and the actual disk cartridge set, and compare the expected file set and the actual file set of the corresponding disk cartridge to generate difference records and abnormal object ranges; perform consistency verification on the corresponding delivery files; generate traceability status based on the burning records, post-write verification records and archive logs;

[0060] S300. Obtain the acceptance conclusion based on the difference record, consistency status, and traceability status; when the acceptance is successful, generate an association record and mark it as the current valid delivery relationship; when the acceptance fails, generate a rollback task, and the rollback task records the scope of the abnormal object.

[0061] S400: Receive the execution receipt of the rollback task; set the original delivery relationship to an invalid state according to the rollback task identifier, generate a replacement relationship record and update the state version; re-execute S200 based on the updated object, and update the current valid delivery relationship when the re-verification is successful.

[0062] S100: Obtain the delivery list, disk tray identifier, file metadata, burning record, post-write verification record, archive log, and acceptance rule record; associate and bind the delivery task identifier, list version, file version, and rule version to generate an acceptance task record; generate the expected disk tray set and expected file set based on the delivery list, and generate the actual disk tray set and actual file set based on the disk tray identifier and file metadata.

[0063] This step is executed by the data receiving module, association binding module, target data extraction module, and test data set acquisition module of the automatic acceptance device. The automatic acceptance device is located in a Blu-ray storage management server, a delivery management server, or a separate server communicating with the Blu-ray storage system. After receiving the acceptance start command, the automatic acceptance device queries the data record corresponding to the delivery task based on the delivery task identifier in the acceptance start command. The acceptance start command is generated when the Blu-ray media has been written, the post-write verification record has been formed, and the disk cartridge enters the delivery-ready state. In another embodiment, the acceptance start command is written to the automatic acceptance device by the delivery management personnel before the disk cartridge leaves the warehouse.

[0064] The delivery list is a file or form record that records the disk cartridges and delivered documents included in the delivery task. The delivery list includes a delivery order number, delivery batch, multiple disk cartridge identification codes, multiple file identifiers corresponding to each disk cartridge, file version, file size, and file summary. The disk cartridge identification code is an identification code that establishes a correspondence between the disk cartridge and the actual disk cartridge; when a delivery task includes multiple disk cartridges, each disk cartridge has its own identification code. The file metadata is a data record describing the attributes of the delivered documents; in this embodiment, the file metadata includes a file identifier, file name, file version, file size, file summary, Blu-ray media identifier, and disk cartridge identification code. The file identifier corresponds to one delivered document in the same delivery task; when files with the same name have different file versions, each file version forms a separate file metadata record.

[0065] The burning records originate from the burning control system; each burning record includes a burning task identifier, Blu-ray media identifier, disc tray identifier, set of files to be written, file version, burning time, and task status. The post-write verification records originate from the burning control system or media read verification program; each post-write verification record includes a burning task identifier, file identifier, file version, read file digest, verification time, and status version. The archive logs originate from the archive management system; each archive log includes an archive task identifier, delivery task identifier, burning task identifier, Blu-ray media identifier, file identifier, file version, archive time, and task status. The acceptance rule records originate from the rule record storage area; each acceptance rule record includes a rule version, a set of necessary fields, a set of necessary objects, version matching conditions, status validity conditions, time sequence conditions, exception classification conditions, rollback action mapping relationships, and idempotent processing conditions.

[0066] The data receiving module queries the delivery management system, disc scanner, Blu-ray storage system, burning control system, and archiving management system based on the delivery task identifier. The retrieved records retain the source record identifier and timestamp. The delivery management system returns a delivery list and its version; the disc scanner returns the identifiers of the multiple discs actually read; the Blu-ray storage system returns the file metadata within the disc based on the Blu-ray media identifier; the burning control system returns the burning record, write result record, and post-write verification record; and the archiving management system returns the archiving log. The data receiving module matches the retrieved records with the delivery task identifier; if the delivery task identifiers in the records do not match, the corresponding record is written to the exception record and not included in the current acceptance task record.

[0067] The association and binding module assigns an acceptance task identifier to this acceptance process; it writes the acceptance task identifier, delivery task identifier, delivery number, delivery batch, inventory version, document version, rule version, and status version into the acceptance task record. The status version indicates the processing order of acceptance records under the same delivery task; an initial status version is generated during the initial acceptance, and subsequent status versions are generated based on the updated object after supplementary delivery, re-engraving, or cartridge replacement. The acceptance task record also records the source record identifier and data summary of each input object; the data summary is generated based on the delivery task identifier, inventory version, document version, cartridge identifier code, and rule version in this input record.

[0068] Before generating an acceptance task record, the automatic acceptance device queries historical acceptance task records with the same delivery task identifier. It then compares the current input data summary and status version with those in the historical acceptance task records. If both the data summary and status version are the same, the historical acceptance task record is read according to idempotent processing conditions, and no duplicate acceptance task record is created. If the data summary is different but the status version is the same, the current input is written to an exception record, and the original acceptance task record is not updated. If the status version is higher than that of a historical acceptance task record, a new acceptance task record is generated for the current input. During the acceptance period, the rule version associated with the acceptance task record remains unchanged. If the rule version changes during the acceptance period, the current acceptance still references the original rule version, and the new rule version is associated in subsequent acceptance task records.

[0069] The target data extraction module reads the delivery fields according to the data format of the delivery list. In one implementation, the delivery list is a spreadsheet or a structured document; the target data extraction module directly extracts the delivery order number, delivery batch, disk identification code, file identifier, file version, file size, and file summary according to the field mapping relationship. In another implementation, the delivery list is an image file or a layout file; the character segment recognition module identifies multiple character segments in the delivery list and the position information of each character segment, the character segment sorting module generates sorted data according to the position information, and the target data extraction module extracts the corresponding fields from the sorted data according to the field mapping relationship to generate standard delivery field records.

[0070] The field mapping relationship records the correspondence between field names in the delivery list and standard delivery fields; for example, "media box number," "disk box number," or pre-configured list field names are mapped to disk box identifiers, and "file number" or pre-configured file field names are mapped to file identifiers. The field mapping relationship is limited by the rule version; it will not be changed during this acceptance process. The target data extraction module performs integrity checks on the standard delivery field records and the necessary field set; if the delivery number, disk box identifier, file identifier, file version, or file summary is not extracted, an exception record corresponding to the missing necessary list field is generated, and the unextracted field and its corresponding character field are recorded in the acceptance task record.

[0071] The test data set acquisition module generates a set of expected disk cartridges based on the standard delivery field records. Specifically, it writes multiple disk cartridge identifiers from the standard delivery field records into the expected disk cartridge set; when the same disk cartridge identifier appears repeatedly, the duplicate records are merged based on the disk cartridge identifier, and the delivery files referenced by each record are retained. The test data set acquisition module then groups the file metadata in the standard delivery field records based on the disk cartridge identifier; it establishes a correspondence between the metadata of multiple files with the same disk cartridge identifier and the corresponding expected disk cartridge, generating a set of expected files for each expected disk cartridge. Each file metadata record in the expected file set includes the file identifier, file version, file size, file summary, and disk cartridge identifier.

[0072] The test data set acquisition module generates a set of actual disc cartridges based on multiple disc cartridge identification codes read by the disc cartridge scanning terminal. For each disc cartridge identification code read, the scanning terminal records the reading time, terminal identifier, and reading status. If a disc cartridge identification code cannot be recognized, the disc cartridge is written to an error record, while retaining the original identification code information returned by the scanning terminal. When the same disc cartridge identification code corresponds to multiple actual disc cartridges, the disc cartridge identification code is written to a duplicate object record. For successfully read disc cartridge identification codes, the test data set acquisition module queries the Blu-ray media identifier based on the disc cartridge identification code, and then reads the media file directory and file metadata based on the Blu-ray media identifier.

[0073] The test data set acquisition module groups the read file metadata according to the actual disk tray identifier code; it establishes a correspondence between the metadata of multiple files within the same actual disk tray and the corresponding tested disk tray, generating a test file set corresponding to each tested disk tray. When a file record exists in the media file directory but the file metadata is missing, the file identifier and file name in the file directory are retained, and an exception record corresponding to the missing file metadata is generated; when the disk tray identifier code recorded in the file metadata is inconsistent with the disk tray identifier code read by the scanning terminal, both disk tray identifier codes are retained, and this inconsistency is written to the exception record for S200 to generate a difference record.

[0074] In a specific implementation scenario, the delivery task is identified as T20260806001, and the delivery list records disk cartridges P001 and P002; disk cartridge P001 corresponds to files F001, F002, and F003, and disk cartridge P002 corresponds to files F004 and F005. The disk cartridge scanning terminal reads disk cartridges P001 and P002; the Blu-ray storage system returns files F001, F002, and F003 from disk cartridge P001, and files F004 and F005 from disk cartridge P002. The automatic acceptance device associates and binds the list version V1, each file version, rule version R1, and initial state version to generate an acceptance task record; it forms a desired disk cartridge set and a corresponding desired file set based on the delivery list, and forms a measured disk cartridge set and a corresponding measured file set based on the scan results and media file metadata.

[0075] The acceptance task record generated in this step includes acceptance task identifier, delivery task identifier, delivery number, delivery batch, list version, document version, rule version, status version, data summary, and source record identifier. The expected disk set and expected file set record the disk-file correspondence represented by the delivery list. The actual disk set and actual file set record the disk-file correspondence in the actual disks. The above acceptance task record, expected disk set, expected file set, actual disk set, actual file set, and the exception record generated in S100 are jointly written into the data record area of ​​this acceptance task and used as input for S200 to perform disk-level comparison, file-level comparison, consistency verification, and traceability status generation.

[0076] S200: Compare the expected disk cartridge set and the actual disk cartridge set, and compare the expected file set and the actual file set of the corresponding disk cartridge to generate difference records and abnormal object ranges; perform consistency verification on the corresponding delivery files; generate traceability status based on the burning record, post-write verification record and archive log.

[0077] This step is performed by the data verification module in the automatic acceptance device. The data verification module receives the acceptance task record, expected disk set, expected file set, actual disk set, and actual file set generated by S100; simultaneously, it reads the acceptance rule record, burning record, write result record, post-write verification record, and archive log associated with the acceptance task record. The corresponding disk set refers to the disk set with the same disk set identifier code in both the expected disk set and the actual disk set; the corresponding delivery file refers to the delivery file with the same file identifier in the file metadata of both the expected file set and the actual file set of the corresponding disk set.

[0078] The data verification module initiates this step upon receiving all output objects from S100 and confirming that the acceptance task record is in the current state version. If the expected or actual disk set has not yet been formed, the data verification module does not perform set comparison and writes the missing set name, source record identifier, and acceptance task identifier into the exception record. If the rule version of the acceptance task record is inconsistent with the rule version of the acceptance rule record, the data verification module retains the original input record, writes the version mismatch status into the exception record, and does not use the unbound acceptance rule record.

[0079] The data verification module first compares the expected cartridge set with the measured cartridge set. For cartridge identifiers that exist in the expected cartridge set but not in the measured cartridge set, a missing object record is generated for the corresponding cartridge. For cartridge identifiers that exist in the measured cartridge set but not in the expected cartridge set, a redundant object record is generated for the corresponding cartridge. If the same cartridge identifier corresponds to multiple read records in the measured cartridge set, or if the Blu-ray media identifiers of multiple cartridges point to the same cartridge identifier, a duplicate object record is generated for the corresponding cartridge. The missing object records, redundant object records, and duplicate object records for each cartridge are all written to the difference record, which also records the object level, cartridge identifier, expected value, measured value, source record identifier, and status version.

[0080] After the disk cartridge layer comparison is completed, the data verification module extracts the corresponding disk cartridges with the same disk cartridge identifier code from the expected disk cartridge set and the actual disk cartridge set. For each corresponding disk cartridge, it reads the expected file set corresponding to the expected disk cartridge and the actual file set corresponding to the actual disk cartridge. For file identifiers that exist in the expected file set but not in the actual file set, a missing object record corresponding to the delivery file is generated; for file identifiers that exist in the actual file set but not in the expected file set, a redundant object record corresponding to the delivery file is generated; when the same file identifier appears in multiple file metadata records in the same actual file set, a duplicate object record corresponding to the delivery file is generated.

[0081] The data verification module also compares the disk cartridge to which the file belongs. Specifically, it queries the entire set of tested files based on the file identifier for the actual disk cartridge identifier code corresponding to the file. If the actual disk cartridge identifier code is inconsistent with the disk cartridge identifier code corresponding to the same file identifier in the standard delivery field record, the file identifier, the disk cartridge identifier code in the standard delivery field record, the disk cartridge identifier code in the file metadata record, and the source record identifier are written into the difference record. The object level record of this difference record is the delivered file, and the exception type record is "file belongs to disk cartridge error". If the file also exists in another set of tested files within the delivery task, the file is not recorded as a missing file in the entire delivery task, but rather as "file belongs to disk cartridge error".

[0082] In one implementation, the comparison of the disk tray layer and the file layer is performed directly based on the disk tray identifier and the file identifier; in another implementation, the file identifier is composed of the file name and a unique ID recorded in the delivery list. When file names are duplicated in the delivery list, the data verification module distinguishes multiple delivery files based on the unique ID; when the unique ID is missing, multiple records corresponding to the same file name are retained, and a duplicate object record is generated, without merging multiple delivery files separately by file name.

[0083] After the disk compartment layer difference record and file layer difference record are formed, the data verification module performs consistency verification on the delivery files in the expected file set and the actual file set that have the same disk compartment identifier code and the same file identifier. The data verification module reads the file version, file size, and file digest from the expected file set, and reads the file version, file size, and file digest of the corresponding file from the actual file set; it compares each item according to the set of file consistency fields in the acceptance rule record. When the file version, file size, and file digest are all consistent, the consistency status of the corresponding delivery file is marked as valid; if any one of them is inconsistent, a field difference record is generated, and the consistency status is marked as invalid.

[0084] The field difference record includes file identifier, disk compartment identifier, field name, expected value, measured value, file version, source record identifier, and status version. For example, if the file version of delivery list record file F003 is V3, and the file version of the measured file metadata record is V2, the field name in the field difference record is file version, the expected value is V3, and the measured value is V2. When the file digests are inconsistent, the field name is file digest, recording both the file digest from the delivery list and the file digest obtained from media reading. If the measured file metadata does not contain file size or file digest, the corresponding field is recorded as an unextracted field, and the consistency status is marked as invalid.

[0085] In one implementation, the file digest is directly read from the self-written verification record; in another implementation, the automatic acceptance device reads the delivery file from the Blu-ray media, and the hash value generation module generates a file digest according to a preset digest processing method, then compares the generated file digest with the file digest in the delivery list. The digest processing method is defined by the rule version in the acceptance rule record; the expected file digest and the actual measured file digest within the same acceptance task use the same digest processing method. When the digest processing method changes, the new digest processing method is used in subsequent acceptance task records.

[0086] After consistency verification, the data verification module queries the Blu-ray media identifier based on the disc tray identifier; and queries the burning record, write result record, post-write verification record, and archive log based on the Blu-ray media identifier and file identifier. The burning record should record the file version of the currently delivered file for the burning task; the write result record should record the writing status of the burning task for that file version; the post-write verification record should record the read file digest and verification status for the same file version; and the archive log should record the archive status of the same burning task or the same file version.

[0087] The data verification module extracts the source record identifier, file version, status version, and timestamp from the aforementioned records. It then matches the file version in the file metadata against the file versions in the burning records, write result records, post-write verification records, and archive logs. A version matching status is generated when the file version in each record matches the file version bound to the current acceptance task record; a version mismatch status is generated when a record references an older file version or does not record a file version. For cases where the same disk cartridge has been burned multiple times, the data verification module filters the burning records referenced by the current acceptance task based on the file version and status version; historical burning records are retained in the acceptance log and do not participate in the generation of the current traceability status.

[0088] The data verification module checks the task status of each record according to the validity conditions. A valid status result is generated when the task status of the burning record is completed, the write status of the write result record is valid, the verification status of the post-write verification record is valid, and the task status of the archived log is completed. A invalid status result is generated when any record is in a failed, obsolete, or invalid state. If a record is missing, the missing record type, file identifier, Blu-ray media identifier, and query conditions are written to the exception record.

[0089] The data verification module compares the timestamps of each record according to the time sequence condition. If the burning time of the record is earlier than the verification time of the post-write verification record, and the verification time of the post-write verification record is not later than the archiving time of the archived log, a valid time sequence result is formed. If a timestamp is missing, or the archiving time of the same file version is earlier than the burning time, or the post-write verification time is earlier than the burning time, an invalid time sequence result is formed. If the acceptance rule record separately records the business configuration where the archiving task occurred before the post-write verification, the data verification module performs the comparison according to the time sequence condition corresponding to that rule version, without changing the rule version associated with this acceptance task record.

[0090] When the version matching status, status validity result, and time sequence validity result are all valid, the data verification module marks the traceability status of the corresponding delivery file as valid. If there are missing records, version mismatches, invalid statuses, or time sequence discrepancies, the traceability status of the corresponding delivery file is marked as invalid. When the disk contains multiple delivery files, the data verification module generates the traceability status for each delivery file separately. If any of the multiple delivery files has an invalid traceability status, the file identifier is written into the traceability record corresponding to the disk.

[0091] The data verification module generates anomaly object ranges based on the object hierarchy, cartridge identifier, and file metadata in the difference records. When a cartridge is missing, redundant, duplicated, or has an anomalous cartridge identifier, the anomaly object range records the corresponding cartridge identifier. When a file is missing, redundant, duplicated, belongs to an incorrect cartridge, has an inconsistent file version, inconsistent file size, or inconsistent file digest, the anomaly object range records the corresponding file identifier, file version, and cartridge identifier. When burning records, write result records, post-write verification records, or archive logs are missing, the anomaly object range records the affected file identifier and Blu-ray media identifier. When an anomaly record involves multiple files, multiple file identifiers are written into the same anomaly object range, and the anomaly type for each file is recorded.

[0092] In a specific implementation scenario, the expected cartridge set includes P001 and P002, and the actual cartridge set includes P001 and P002; the expected file set for cartridge P001 includes F001, F002, and F003, and the actual file set includes F001 and F002; the actual file set for cartridge P002 includes F003 in addition to F004 and F005. The data verification module does not generate a difference record at the cartridge level; it generates a missing object record for file F003 corresponding to cartridge P001 at the file level, and generates an error record for the cartridge to which file F003 belongs after querying all actual file sets. The abnormal object range records file F003, expected cartridge P001, and actual cartridge P002; the abnormal object range serves as the input for S300 to generate a re-burning task or cartridge replacement task.

[0093] This step ultimately generates a difference record, a field difference record, the consistency status of each delivered document, the traceability status of each delivered document, and the scope of abnormal objects. The difference record retains records of missing objects, redundant objects, and duplicate objects at the disk and file levels. The scope of abnormal objects records the affected disks or delivered documents. The above output objects are associated with the acceptance task identifier, status version, and rule version, and sent to S300. S300 obtains the acceptance conclusion based on the difference record, consistency status, and traceability status, and generates a processing object for the rollback task based on the scope of abnormal objects.

[0094] S300. Obtain the acceptance conclusion based on the difference record, consistency status, and traceability status; when the acceptance is successful, generate an association record and mark it as the current valid delivery relationship; when the acceptance fails, generate a rollback task, and the rollback task records the scope of the abnormal object.

[0095] This step is executed by the acceptance result determination module, rollback task generation module, and ledger management module in the automatic acceptance device. The acceptance result determination module receives the difference records, field difference records, consistency status, traceability status, and scope of abnormal objects generated by S200; it reads the acceptance task records and their associated acceptance rule records generated by S100. The acceptance conclusion includes acceptance passed status and acceptance failed status; the association record is a data record that records the current correspondence between delivery tasks, disks, and delivery documents; the rollback task is a data record that records the scope of abnormal objects, processing actions, original object version, completion conditions, and task status.

[0096] The acceptance result determination module checks the discrepancy records according to the preset acceptance conditions in the acceptance rules record. If there are no missing object records, redundant object records, or duplicate object records in the discrepancy records, and no discrepancy record corresponding to an error in the disk to which the file belongs, a completeness valid state is formed; if any of the above records are present in the discrepancy records, a completeness invalid state is formed. If the actual set of disks contains a disk not recorded in the delivery list, even if the file in that disk does not appear in the expected file set, a redundant object record is still generated, resulting in a completeness invalid state.

[0097] The acceptance result determination module then summarizes the consistency status and traceability status generated by S200. When all corresponding deliverables have a valid consistency status and all deliverables have a valid traceability status, a valid consistency result and a valid traceability result are generated. If any deliverable has an invalid consistency status, a invalid consistency result is generated; if any deliverable has an invalid traceability status, a invalid traceability result is generated. The acceptance result determination module associates the completeness status, consistency status, and traceability status with the acceptance task identifier and status version to generate acceptance result information.

[0098] When all three statuses—completeness, consistency, and traceability—are valid, the acceptance result determination module records the acceptance conclusion as "acceptance passed." If any of these statuses is invalid, the acceptance conclusion is recorded as "acceptance failed." The acceptance conclusion also includes the difference record identifier, field difference record identifier, abnormal object scope identifier, rule version, and generation time. For cases where S100 has already generated abnormal records for missing necessary fields in the manifest, the acceptance result determination module records the acceptance conclusion as "acceptance failed" and does not mark the delivery manifest correspondence for which incomplete field extraction has not been completed as a currently valid delivery relationship.

[0099] Upon successful acceptance, the acceptance result determination module generates a relationship record based on the acceptance task record, the expected disk set, the actual disk set, the expected file set, and the actual file set. This relationship record includes the delivery task identifier, acceptance task identifier, delivery number, delivery batch, disk identifier code, Blu-ray media identifier, file identifier, file version, rule version, status version, and source record identifier. When one disk corresponds to multiple delivery files, the relationship record records the file identifier and file version for each file, and establishes a correspondence between multiple delivery files and the same disk set using the disk identifier code.

[0100] The acceptance result determination module marks the associated relationship record as a currently valid delivery relationship and updates the task status of the acceptance task record to the acceptance passed status. When there are historical associated relationship records with the same delivery task identifier, the acceptance result determination module queries the status version of the historical associated relationship record; if the historical associated relationship record is already in an invalid state, its status is retained; if the historical associated relationship record is still marked as a currently valid delivery relationship, the current acceptance conclusion and status version are written into the exception record, so that two sets of currently valid delivery relationships are not formed under the same status version.

[0101] The ledger management module writes acceptance task records, discrepancy records, consistency status, traceability status, acceptance conclusions, and relationship records into the acceptance ledger. The acceptance ledger records each acceptance according to the delivery task identifier and status version; the status version record corresponding to the current valid delivery relationship is the current valid version. When the pallet outbound process reads the acceptance ledger, it queries the current valid version based on the delivery task identifier and reads the relationship records under that version that are marked as current valid delivery relationships.

[0102] In one implementation, the ledger management module generates a structured acceptance report based on the acceptance conclusion, discrepancy records, consistency status, and traceability status. The structured acceptance report records the acceptance task identifier, delivery number, delivery batch, number of disks / cassettes, number of delivered documents, discrepancy records, field discrepancy records, traceability status, and acceptance conclusion. The structured acceptance report and related records reference the same status version; changes in the report format do not alter the object identifier and status version in the related records.

[0103] When acceptance fails, the rollback task generation module reads the mapping relationship between the scope of the abnormal object and the rollback action. The rollback action mapping relationship records the correspondence between the abnormal classification conditions and the processing actions; the processing actions include resubmission, re-burning, and cartridge replacement. The rollback task generation module selects the corresponding processing action based on the object level, abnormal type, cartridge identifier, file identifier, and original object version in the scope of the abnormal object, and generates a rollback task identifier.

[0104] If any fields are missing from the required field set, or if the corresponding attachments to the delivery list are not received, the rollback task generation module generates a supplementary delivery task. The supplementary delivery task records the missing fields, the delivery list identifier, and the list version in the exception scope; the processing action is recorded as "supplementary delivery"; the original object version records the current list version; and the completion condition records that the supplemented delivery list includes the corresponding fields and forms the updated list version. After the supplementary delivery task is generated, the task status of the acceptance task record is updated to the task status associated with the rollback task; the current delivery relationship remains unchanged.

[0105] When the scope of the anomaly includes delivered files, and there are issues such as missing files, inconsistent file versions, inconsistent file digests, or invalid post-write verification records, the rollback task generation module generates a re-burning task. The re-burning task records the rollback task identifier, acceptance task identifier, disk tray identifier, file identifier, original file version, anomaly type, processing action, completion conditions, and task status. When the scope of the anomaly includes multiple delivered files, the re-burning task records multiple file identifiers and their respective original file versions. Completion conditions include generating an updated file version, burning record, write result record, and post-write verification record.

[0106] When the scope of the abnormal object is the disc tray, and there are disc tray identifier errors, unrecognizable Blu-ray media identifiers, or invalid post-write verification records for multiple delivered files, the rollback task generation module generates a disc tray replacement task. The scope of multiple delivered files is limited by the quantity relationship conditions in the acceptance rule record; when these quantity relationship conditions are met, the abnormal object scope records the disc tray identifier code and the identifiers of the affected files in the disc tray. The disc tray replacement task records the original disc tray identifier code, the original Blu-ray media identifier, the processing action, the completion conditions, and the task status; the completion conditions include generating and updating the disc tray identifier code, updating the Blu-ray media identifier, updating file metadata, burning records, and post-write verification records.

[0107] When the same range of exception objects simultaneously meets the exception classification conditions for both re-creation and replacement tasks, the rollback task generation module selects a processing action according to the rollback action mapping relationship recorded in the acceptance rules. If the rollback action mapping relationship does not record a corresponding processing action, the generation rules do not match the corresponding exception record, and no rollback task without a defined processing action is generated. When a delivery task contains multiple non-overlapping ranges of exception objects, multiple rollback tasks are generated separately; each rollback task records its own range of exception objects and the original object version.

[0108] In a specific implementation scenario, S200 generates an error record for the disc drive to which file F003 belongs. The scope of the abnormal object is file F003, the expected disc drive is P001, and the measured disc drive is P002. The rollback action mapping relationship maps the disc drive error to a re-burning task. The rollback task generation module generates a re-burning task RT001. RT001 records file F003, original file version V1, target disc drive P001, original disc drive P002, processing action as re-burning, and task status as pending execution. The rollback task identifier and the scope of the abnormal object are sent to the burning control system. After the burning control system completes the re-burning, it returns an execution receipt, which enters S400.

[0109] This step outputs the acceptance conclusion, relationship record, current valid delivery relationship, and acceptance log record when acceptance is successful; and outputs the acceptance conclusion, rollback task, and acceptance log record when acceptance fails. The rollback task records the scope of abnormal objects generated by S200, and retains the original object version and acceptance task identifier; the rollback task is executed by the delivery management system, burning control system, or disc management system. After the above systems complete their processing actions, they generate an execution receipt based on the rollback task identifier; S400 receives the execution receipt and queries the rollback task and its abnormal object scope formed in this step based on the rollback task identifier.

[0110] S400: Receive the execution receipt of the rollback task; set the original delivery relationship to an invalid state according to the rollback task identifier, generate a replacement relationship record and update the state version; re-execute S200 based on the updated object, and update the current valid delivery relationship when the re-verification is successful.

[0111] This step is performed by the re-inspection processing module and the ledger management module in the automatic acceptance device. The re-inspection processing module receives an execution receipt from the delivery management system, the burning control system, or the disc drive management system; the execution receipt includes a rollback task identifier, processing action, original object version, updated object identifier, updated object version, and task status. In one embodiment, the execution receipt also records the updated disc drive identifier code, the updated Blu-ray media identifier, the new burning task identifier, the new post-write verification record identifier, the execution time, and the source record identifier.

[0112] The re-verification processing module initiates relationship updates when the task status of the execution receipt is "completed." When the task status of the execution receipt is "in progress" or "failed," the execution receipt is written to the acceptance log, but the original delivery relationship status is not updated. If a rollback task does not return an execution receipt within the time specified by the completion conditions, the original acceptance task status and the original delivery relationship status are maintained, and the rollback task identifier, task status, and last received time are written to the acceptance log. Relationship updates are only initiated when a subsequent execution receipt with a "completed" task status is received.

[0113] The re-verification processing module queries the rollback task generated by S300 based on the rollback task identifier; it reads the scope of the exception object, the processing action, the original object version, and the original acceptance task identifier from the rollback task. If the processing action, original object version, or updated object identifier in the execution receipt does not match the rollback task, the mismatch field is written to the exception record, and the status version is not updated. If the rollback task identifier in the execution receipt already corresponds to a completed execution receipt, idempotent processing is performed based on the data summary and status version; duplicate execution receipts do not generate replacement relationship records again, nor are they updated with the status version again.

[0114] When the processing action is a supplementary submission, the verification processing module obtains the updated delivery list and the updated list version based on the execution receipt; it associates the updated delivery list with the original delivery task identifier and retains the original list version. The verification processing module extracts the updated delivery list according to the field mapping relationship in S100, and generates updated standard delivery field records, expected disk set, and expected file set; if the actual disk set and actual file set have not changed, it continues to reference the actual disk set and actual file set with the same source record identifier in the original state version. When the supplementary submission task does not involve disk or file replacement, no replacement relationship record corresponding to the disk or file is generated; the new list version is written to the subsequent state version.

[0115] When the processing action is re-burning, the verification module obtains the updated file identifier, updated file version, new burning task identifier, new write result record, new post-write verification record, and new archive log based on the execution receipt. It then queries the original association records based on the file identifier and original file version in the rollback task, setting the association records corresponding to the original file versions to an invalid state. Delivered files in the original cartridge that were not re-burned retain their original association records; only the original file version relationships of files recorded within the scope of the exception object are set to an invalid state.

[0116] The verification processing module writes the original file version, updated file version, rollback task identifier, file identifier, disk tray identifier, replacement time, and relationship status into the replacement relationship record. In the replacement relationship record, the original object identifier is the original file identifier and the original file version, and the updated object identifier is the updated file identifier and the updated file version. The relationship status of the original association record is written as invalid, and the relationship status corresponding to the updated file is recorded as not having formed a currently valid delivery relationship before verification. The updated file version is written into the actual test file set and replaces the original file version record with the same file identifier.

[0117] When the processing action is cartridge replacement, the verification module obtains the updated cartridge identifier, updated Blu-ray media identifier, updated file metadata, new burning record, new write result record, new post-write verification record, and new archive log based on the execution receipt. It then queries the corresponding association record for the original cartridge based on the original cartridge identifier in the rollback task and sets the association record corresponding to the original cartridge identifier to an invalid state. Multiple delivery file relationships within the original cartridge are recorded as invalid along with the original cartridge relationships; delivery file relationships not included in the original cartridge remain in their original state.

[0118] The re-verification processing module writes the original disc tray identifier, original Blu-ray media identifier, updated disc tray identifier, updated Blu-ray media identifier, rollback task identifier, replacement time, and relationship status into the replacement relationship record. The updated disc tray identifier is written to the actual tested disc tray set; based on the updated Blu-ray media identifier, the file metadata in the updated disc tray is read, and the corresponding actual tested file set for the updated disc tray is generated. If file metadata in the updated disc tray is missing, the missing file metadata is written to the exception record, and the re-verification is not initiated.

[0119] After the replacement relationship record is generated, the re-verification processing module generates a subsequent status version based on the original status version. The subsequent status version establishes a correspondence with the original delivery task identifier and the original acceptance task identifier, and records the rollback task identifier and execution receipt identifier. The acceptance task record, difference record, acceptance conclusion, and association record in the original status version retain the original record content; the subsequent status version records the updated delivery list, disk identification code, file metadata, burning record, post-write verification record, and archive log.

[0120] The verification processing module regenerates the input to S200 based on the updated objects. When the supplementary delivery task is completed, the updated objects include the updated delivery list, standard delivery field records, expected disc cartridge set, and expected file set; when the reburning task is completed, the updated objects include the updated file version, updated test file set, new burning record, new write result record, new post-write verification record, and new archive log; when the cartridge replacement task is completed, the updated objects include the updated disc cartridge identifier, updated Blu-ray media identifier, updated test disc cartridge set, updated test file set, and corresponding burning and archiving records.

[0121] The re-inspection processing module writes the subsequent status version, the updated object, and the rule version associated with the original acceptance task record into the re-inspection task record, and re-executes S200 based on the updated object. When re-executing S200, the process still follows the order of comparing the expected disk set with the actual disk set, comparing the expected file set of the corresponding disk set with the actual file set, verifying the consistency of delivered documents, and tracing the burning and archiving records; it generates the corresponding difference record, the scope of abnormal objects, the consistency status, and the traceability status for the re-inspection. If the rule version changes during the re-inspection, the current re-inspection still references the rule version associated with the original acceptance task record.

[0122] If the generated discrepancy records from the re-verification process do not contain any missing, redundant, or duplicate object records, and both the consistency and traceability statuses are valid, a re-verification pass status is generated. The re-verification processing module generates a new association record based on the updated object and marks the new association record as the currently valid delivery relationship. The new association record includes the subsequent status version, updated disk tray identifier or updated file version, rule version, and source record identifier; the original association record remains in an invalid state.

[0123] When a re-verification fails, the re-verification processing module invokes the rollback action mapping relationship of S300 based on the scope of the abnormal objects corresponding to the re-verification result, generating a new rollback task. The new rollback task references the subsequent state version and records the scope of abnormal objects generated in this re-verification and the updated object version. After the new rollback task is completed, it receives the execution receipt again and generates the subsequent state version in the same way. When the maximum number of retries recorded in the acceptance rules is reached, the re-verification processing module no longer automatically generates new rollback tasks, but instead writes the re-verification failure status, the scope of abnormal objects, and the number of retries into the acceptance log.

[0124] In a specific implementation scenario, the original file version V1 of file F003 corresponds to the re-burning task RT001. After the burning control system completes the re-burning, it returns an execution receipt, which records the updated file version V2, the new burning task identifier B002, the new post-write verification record identifier C002, and the task status as completed. The verification processing module queries the association record corresponding to the original file version V1 based on RT001 and sets the record to an invalid state; it generates a replacement relationship record between the original file version V1 and the updated file version V2, and updates the status version from SV1 to SV2. The verification processing module writes the updated file version V2 of file F003 into the actual file set corresponding to disk cartridge P001, and then executes S200. When the file version, file size, and file digest of file F003 are consistent with the expected file set, and the new burning record, post-write verification record, and archive log meet the version matching condition, status validity condition, and time sequence condition, the verification result is recorded as passed, and the updated association record of file F003 is marked as a currently valid delivery relationship.

[0125] The ledger management module writes execution receipts, records of invalid original relationships, records of replaced relationships, updated status versions, re-inspection difference records, re-inspection consistency status, re-inspection traceability status, re-inspection results, and new association records into the acceptance ledger. The acceptance ledger stores the initial acceptance status version and subsequent status versions according to the delivery task identifier; the currently valid version points to the status version corresponding to the most recent successful re-inspection. When querying delivery tasks in the pallet outbound process or customer signing process, the currently valid delivery relationships under the current valid version are read; original delivery relationships in an invalid state and updated relationships that failed re-inspection are retained in the acceptance ledger but are not returned as currently valid delivery relationships.

[0126] Example 2: Figure 2 A structural block diagram of a Blu-ray storage customer acceptance data processing method according to an embodiment of the present invention is shown. Figure 2 As shown, the structure may include:

[0127] The data receiving and collection generation module 01 is used to acquire delivery lists, disk tray identifiers, file metadata, burning records, post-write verification records, archiving logs, and acceptance rule records; associate and bind delivery task identifiers, list versions, file versions, and rule versions to generate acceptance task records; generate expected disk tray sets and expected file sets based on the delivery lists, and generate actual disk tray sets and actual file sets based on the disk tray identifiers and file metadata; specifically, the data receiving and collection generation module receives delivery lists and list versions provided by the delivery management system, disk tray identifiers provided by the disk tray reading device, file metadata provided by the Blu-ray storage system, burning records and post-write verification records provided by the burning control system, archiving logs provided by the archiving management system, and acceptance rule records; the delivery list includes a delivery order number, delivery batch, disk tray identifier, file identifier, file version, file size, and file summary, and the file metadata includes a file identifier, file version, file size, file summary, Blu-ray media identifier, and disk tray identifier. The data receiving and set generation module queries the aforementioned records according to the delivery task identifier and compares the delivery task identifiers in each record. When the delivery task identifiers are consistent, the list version, file version, and rule version are written into the acceptance task record. When the delivery task identifiers are inconsistent, the corresponding record is marked as an abnormal record and the source record identifier is retained. The acceptance task record includes the acceptance task identifier, delivery task identifier, delivery number, delivery batch, list version, file version, rule version, and status version. The data receiving and set generation module queries the acceptance task records with the same delivery task identifier based on the data digest and status version. When both the data digest and status version are the same, the original acceptance task record is referenced. When the status version changes, a new acceptance task record is generated. The data receiving and set generation module extracts the disk compartment identifier and file metadata from the delivery list according to the field mapping relationship in the acceptance rule record to form a standard delivery field record. Based on multiple disk compartment identifiers in the standard delivery field record, a desired disk compartment set is generated, and a correspondence is established between multiple file metadata with the same disk compartment identifier and the corresponding desired disk compartment to generate a desired file set. The data receiving and collection generation module generates a set of measured disc cartridges based on the multiple disc cartridge identification codes actually read, queries the Blu-ray media identifier based on the disc cartridge identification code, and reads the file metadata in each disc cartridge based on the Blu-ray media identifier; the file metadata is then associated with the corresponding measured disc cartridges according to the disc cartridge identification code to generate a set of measured files.If necessary fields in the delivery list are not extracted, the disk cartridge identification code cannot be read, or the file metadata is missing, the data receiving and set generation module retains the original input record and forms an exception record; the acceptance task record, expected disk cartridge set, expected file set, actual disk cartridge set, actual file set, burning record, post-write verification record, archive log, and acceptance rule record are transmitted to the data verification module, and the list version, file version, rule version, and status version serve as inputs for the data verification module to perform version matching.

[0128] Data verification module 02, connected to the data receiving and set generation module, is used to compare the expected disk cartridge set and the actual disk cartridge set, and compare the expected file set and the actual file set of the corresponding disk cartridge, generating difference records and abnormal object ranges; performing consistency verification on the corresponding delivery files; and generating traceability status based on the burning record, post-write verification record, and archive log. Specifically, the data verification module receives the acceptance task record, expected disk cartridge set, expected file set, actual disk cartridge set, actual file set, burning record, post-write verification record, archive log, and acceptance rule record output by the data receiving and set generation module, and reads the rule version and status version associated with the acceptance task record. The data verification module first compares the expected disk cartridge set and the actual disk cartridge set according to the disk cartridge identifier code; for disk cartridges that exist in the expected disk cartridge set but not in the actual disk cartridge set, a missing object record is written; for disk cartridges that exist in the actual disk cartridge set but not in the expected disk cartridge set, a redundant object record is written; and when the same disk cartridge identifier code corresponds to multiple actual disk cartridges, a duplicate object record is written. After completing the disk cartridge set comparison, the data verification module extracts the corresponding disk cartridges with the same disk cartridge identifier code and reads the expected file set and the actual file set of the corresponding disk cartridge respectively. Deliverable files that exist in the expected file set but not in the actual file set are written to a missing object record; deliverable files that exist in the actual file set but not in the expected file set are written to a redundant object record; when the same file identifier corresponds to multiple actual files, a duplicate object record is written. The data verification module also queries the actual disk cartridge identifier code corresponding to the deliverable file in multiple actual file sets based on the file identifier. When the actual disk cartridge identifier code is inconsistent with the disk cartridge identifier code recorded in the expected file set, the file identifier, expected disk cartridge identifier code, and actual disk cartridge identifier code are written to a difference record. For deliverable files with the same disk cartridge identifier code and the same file identifier in both the expected file set and the actual file set, the data verification module compares the file version, file size, and file digest. When all of these fields are consistent, a valid consistency state is generated; if any one of them is inconsistent, a field difference record is generated, forming an invalid consistency state. The data verification module queries the Blu-ray media identifier based on the disc tray identifier code, and then queries the burning records, write result records, post-write verification records, and archive logs based on the Blu-ray media identifier and file metadata. It extracts the source record identifier, file version, status version, and timestamp from each record and compares them according to the version matching conditions, status validity conditions, and time sequence conditions in the acceptance rules record. If the file version in each record matches the file version associated with the acceptance task record, the record status is valid, and the timestamp matches the chronological order of the burning record, post-write verification record, and archive log, the data verification module generates a valid traceability status. If there are missing records, version mismatches, invalid statuses, or inconsistent time sequences, an invalid traceability status is generated.The data verification module forms an abnormal object range based on missing object records, redundant object records, duplicate object records, field difference records, and invalid traceability status. The abnormal object range records the disk identifier, file identifier, file version, abnormal type, and source record identifier. The data verification module then transmits the difference records, abnormal object range, consistency status, and traceability status to the acceptance result determination module. The abnormal object range serves as input to the objects processed in the rollback task, while the consistency status and traceability status serve as input to the acceptance conclusion.

[0129] The acceptance result determination module 03, connected to the data verification module, is used to obtain the acceptance conclusion based on the difference records, consistency status, and traceability status. When the acceptance conclusion is "acceptance passed," an association record is generated and marked as a currently valid delivery relationship. When the acceptance conclusion is "acceptance failed," a rollback task recording the scope of the abnormal objects is generated. Specifically, the acceptance result determination module receives the difference records, scope of abnormal objects, consistency status, and traceability status output by the data verification module, and reads the delivery task identifier, delivery number, delivery batch, rule version, and status version from the acceptance task record. The acceptance result determination module checks the difference records according to the acceptance rule record. When there are no missing object records, redundant object records, duplicate object records, or incorrect disk partition records in the difference records, and the consistency status and traceability status of multiple delivered files are both valid, an acceptance conclusion of "acceptance passed" is generated. When there are missing object records, redundant object records, duplicate object records, or incorrect disk partition records in the difference records, or when the consistency status or traceability status of any delivered file is invalid, an acceptance conclusion of "acceptance failed" is generated. When the acceptance conclusion is "acceptance passed," the acceptance result determination module generates an association record based on the acceptance task record, the measured disc set, and the measured file set. This association record includes a delivery task identifier, delivery number, disc identifier code, Blu-ray media identifier, file identifier, file version, rule version, status version, and source record identifier. The acceptance result determination module marks this association record as a currently valid delivery relationship and establishes a correspondence between the acceptance conclusion, the association record, and the status version. When the acceptance conclusion is "acceptance failed," the acceptance result determination module reads the object level and exception type within the scope of the exception object based on the rollback action mapping relationship in the acceptance rule record. If necessary fields are not extracted, a resubmission task is generated. If the exception object scope includes delivered files and there are missing files, inconsistent file versions, inconsistent file digests, or invalid post-write verification records, a re-burning task is generated. If the exception object scope includes discs and there are disc identifier anomalies, unrecognizable Blu-ray media identifiers, or invalid post-write verification records for multiple delivered files, a disc replacement task is generated. The rollback task includes a rollback task identifier, an exception object range, a processing action, the original object version, completion conditions, and a task status. When multiple non-overlapping exception object ranges exist in a delivery task, the acceptance result determination module generates corresponding rollback tasks for each, maintaining the association between each rollback task and the acceptance task identifier and status version. If the rollback action mapping relationship does not record a corresponding processing action, the acceptance result determination module retains the acceptance failure conclusion and writes the rule mismatch status into the task status of the rollback task.The acceptance result determination module provides the re-inspection processing module with the acceptance conclusion, the current valid delivery relationship, or the rollback task; the rollback task identifier, the scope of abnormal objects, the processing action, and the original object version in the rollback task serve as the input for the re-inspection processing module to match the execution receipt and find the original delivery relationship.

[0130] The re-verification processing module 04, connected to the acceptance result determination module, is used to receive the execution receipt of the rollback task, obtain the updated object based on the execution receipt, set the association record corresponding to the replaced object to an invalid state according to the rollback task identifier, generate a replacement relationship record and update the status version, and call the data verification module to re-perform set comparison, consistency verification and traceability status generation based on the updated object, and update the currently valid delivery relationship when the re-verification passes. Specifically, the re-verification processing module receives the execution receipt returned by the delivery management system, burning control system or disc management system, and queries the rollback task generated by the acceptance result determination module according to the rollback task identifier in the execution receipt; the execution receipt includes the rollback task identifier, processing action, original object version, updated object identifier, updated object version and task status. When the rollback task identifier, processing action and original object version in the execution receipt are consistent with the corresponding content in the rollback task, and the task status is completed, the re-verification processing module obtains the updated object; when the task status is executing or execution failed, the status of the original association record is retained and the status version is not updated. When the processing action is supplementary delivery, the updated objects include the updated delivery list and list version; the verification processing module calls the data receiving and set generation module to regenerate the expected disc cartridge set and expected file set based on the updated delivery list. When the processing action is reburning, the updated objects include the updated file version, new burning record, new write result record, new post-write verification record, and new archive log; the verification processing module queries the association record corresponding to the original file version based on the rollback task identifier and the file identifier in the abnormal object range, sets the association record to an invalid state, and writes the updated file version into the corresponding actual test file set. When the processing action is cartridge replacement, the updated objects include the updated disc cartridge identifier code, updated Blu-ray media identifier, updated file metadata, new burning record, new write result record, new post-write verification record, and new archive log; the verification processing module queries the association record corresponding to the original disc cartridge based on the rollback task identifier and the original disc cartridge identifier code in the abnormal object range, sets the association record to an invalid state, and calls the data receiving and set generation module to generate the updated actual test disc cartridge set and actual test file set. The verification processing module writes the original object identifier, original object version, updated object identifier, updated object version, rollback task identifier, timestamp, and relationship status into the replacement relationship record; generates a subsequent state version based on the original state version, and establishes a corresponding relationship between the subsequent state version and the delivery task identifier, rollback task identifier, and execution receipt.The re-verification processing module transmits the updated expected disk set, expected file set, actual disk set, actual file set, burning record, post-write verification record, and archive log to the data verification module. The data verification module generates re-verification difference records, re-verification anomaly object ranges, re-verification consistency status, and re-verification traceability status in the order of disk set comparison, corresponding disk set file set comparison, delivery file consistency verification, and traceability status generation. When the re-verification difference records do not contain missing, redundant, or duplicate object records, and both the re-verification consistency status and the re-verification traceability status are valid, the re-verification processing module generates a successful re-verification result and generates a new association record based on the updated object, marking the new association record as the current valid delivery relationship. When the re-verification result is an acceptance failure, the re-verification processing module transmits the re-verification anomaly object range to the acceptance result determination module, which then generates a new rollback task. The execution receipt, replacement relationship record, subsequent status version, verification result, and updated current valid delivery relationship are established in correspondence with the delivery task identifier, and are read by the data receiving and set generation module in the subsequent status version acceptance processing.

Claims

1. A method for processing customer acceptance data for Blu-ray storage, characterized in that, include: S100: Obtain the delivery list, disk identification code, file metadata, burning record, post-write verification record, archive log and acceptance rule record; Associate and bind the delivery task identifier, list version, file version, and rule version to generate an acceptance task record; generate the expected disk box set and expected file set based on the delivery list; and generate the actual disk box set and actual file set based on the disk box identifier code and file metadata. S200: Compare the expected disk cartridge set and the actual disk cartridge set, and compare the expected file set and the actual file set of the corresponding disk cartridge to generate difference records and abnormal object ranges; perform consistency verification on the corresponding delivery files; generate traceability status based on the burning records, post-write verification records and archive logs; S300. Obtain the acceptance conclusion based on the difference record, consistency status, and traceability status; when the acceptance is successful, generate an association record and mark it as the current valid delivery relationship; when the acceptance fails, generate a rollback task, and the rollback task records the scope of the abnormal object. S400: Receive the execution receipt of the rollback task; The original delivery relationship is set to invalid state based on the rollback task identifier, a replacement relationship record is generated and the state version is updated; S200 is re-executed based on the updated object, and the current valid delivery relationship is updated when the re-verification is successful.

2. The method according to claim 1, characterized in that, The acceptance task record includes acceptance task identifier, delivery task identifier, delivery number, delivery batch, list version, document version, rule version, and status version; Obtain the acceptance task record with the same delivery task identifier; Idempotent processing is performed based on the data summary and status version; the rule version associated with the acceptance task record remains unchanged during the acceptance period.

3. The method according to claim 2, characterized in that, The expected disk set and expected file set are generated based on the delivery list, including: Based on the field mapping relationship, extract the delivery order number, disk identification code, file metadata, file version and file summary from the delivery list to generate standard delivery field records; Generate the desired disk box set based on the multiple disk box identifier codes recorded in the standard delivery field record; Establish a correspondence between the metadata of files with the same disk tray identifier and the corresponding desired disk tray, and generate a set of desired files.

4. The method according to claim 3, characterized in that, The measured disk cartridge set and measured file set are generated based on the disk cartridge identifier and file metadata, including: A set of actual disk cartridges is generated based on the read disk cartridge identification codes; Read the file metadata corresponding to each disc cartridge based on the Blu-ray media identifier; The file metadata is associated with the corresponding test disk cartridges to generate a set of test files.

5. The method according to claim 4, characterized in that, Generating the difference records and the range of anomalous objects includes: Compare the expected disk box set with the actual disk box set to generate missing object records, redundant object records, and duplicate object records corresponding to the disk boxes; Compare the expected file set and the actual file set of the corresponding disk compartment, and generate missing object records, redundant object records and duplicate object records corresponding to the delivery file; When the disk compartment identifier code in the file metadata record is inconsistent with the disk compartment identifier code in the standard delivery field record, the corresponding delivery file will be written into the difference record. An anomaly object range is generated based on the disk identification code and file metadata in the difference record.

6. The method according to claim 5, characterized in that, The consistency verification includes: For delivered files in the expected file set and the actual file set that have the same file metadata and the same disk identification code, compare the file version, file size and file digest. When the file version, file size, and file digest are all consistent, the consistency status is marked as valid. If one of them is inconsistent, a field difference record is generated, and the consistency status is marked as invalid.

7. The method according to claim 6, characterized in that, The traceability status is generated based on the burning records, post-write verification records, and archived logs, including: Search for Blu-ray media identification based on the disc tray identification code; Based on the Blu-ray media identifier and file metadata, query the burning record, write result record, post-write verification record, and archive log; Retrieve the source record identifier, file version, status version, and timestamp for each record; When each record meets the version matching condition, the status validity condition, and the time sequence condition, the traceability status is marked as a valid status; If there are missing records, version mismatches, invalid states, or inconsistent time sequences, the traceability status will be marked as invalid.

8. The method according to claim 7, characterized in that, Acceptance is considered successful if there are no missing object records, redundant object records, or duplicate object records in the difference records, and both the consistency status and the traceability status are valid. Upon successful acceptance, the associated records include the delivery task identifier, delivery order number, disk identification code, file metadata, file version, rule version, status version, and source record identifier. Record the aforementioned relationship in the acceptance log.

9. The method according to claim 8, characterized in that, When acceptance fails, the rollback task is generated according to the rollback action mapping relationship, including: A supplementary submission task is generated when there are unextracted fields in the required field set. An exception is defined as a delivered file, and a re-creation task is generated when there are missing files, inconsistent file versions, inconsistent file digests, or invalid post-write verification records. An abnormal object is a disk cartridge, and a cartridge replacement task is generated when there is an abnormal disk cartridge identifier, an unrecognizable Blu-ray media identifier, or multiple post-write verification records of delivery files are invalid. The rollback task record includes the rollback task identifier, the scope of the abnormal object, the processing action, the original object version, the completion conditions, and the task status.

10. The method according to claim 9, characterized in that, The execution receipt includes the rollback task identifier, processing action, original object version, updated object identifier, updated object version, and task status; When the processing action is to re-copy, the association record corresponding to the original file version is set to an invalid state; The processing action is to set the association record corresponding to the original disc cartridge identification code to an invalid state when the cartridge is replaced; Write the original object version, the updated object version, the rollback task identifier, and the timestamp into the replacement relationship record and update the status version; Re-execute S200 based on the updated object; When the re-verification passes, the association record corresponding to the updated object is marked as the current valid delivery relationship. When the re-verification fails, a rollback task is generated based on the scope of abnormal objects corresponding to the re-verification result. Write the execution receipt, replacement relationship record, and re-verification results into the acceptance log.

Images