...
- The Repository administrator selects a set of objects to be deposited
- The Repository calls the Gateway PUT Object endpoint once for each object to be deposited; this starts the deposit process
- The Gateway resolves each object into a set of files to be deposited; each file is either copied to the Gateway staging storage area or a link to the file is captured to allow transfer to the Bridge
- The Gateway calls the Bridge Deposit Content endpoint using the object ID as the filegroup identifier and providing an identifier for each file to be deposited
- The Bridge initiates a deposit action for each filegroup in the deposit request
- For each file in each filegroup the Bridge calls the Gateway TBD GET File endpoint to initiate a transfer of the file to the Bridge staging storage location
- As each file transfer into the Bridge staging storage completes, the Bridge compares the checksum of the transferred file to the checksum provided in the deposit request; any mismatches trigger a re-transfer
- Once all files in a filegroup are in Bridge staging storage and all checksums are validated, the status of the deposit is updated to "STAGED_FOR_DEPOSIT"
- The DDP calls the Bridge List Deposits endpoint on a regular schedule to check for new deposits in the "STAGED_FOR_DEPOSIT" state
- For each staged deposit in the Bridge the DDP copies the files from Bridge staging storage into the DDP ingest pipeline and performs a deposit (and replication)
- When the deposit into the DDP is finished, the DDP calls the Bridge Complete Deposit endpoint to inform the Bridge that the deposit is complete
- The Bridge clears the files associated with the completed deposit from Bridge staging storage
- The Repository administrator checks the object status in the Repository; the Repository requests information about the object from the Gateway to provide information.
Gliffy Diagram | ||||
---|---|---|---|---|
|
Delete
Flow
- The Repository manager selects an object to be deleted from preservation storage
- The Repository calls the Gateway DELETE Object endpoint for the object to be deleted
- The Gateway resolves the object into a set of files to be deleted
- The Gateway calls the Bridge Delete Content endpoint with the list of files to be deleted
- The Bridge initiates a delete action for all files in the delete request
- The DDP calls the Bridge List Deletes endpoint on a regular schedule to check for new delete requests
- The DDP performs a delete on each requested file; when all deletes are completed, the DDP calls the Bridge Complete Delete endpoint to inform the Bridge that the delete is complete
- The Repository administrator checks the object status in the Repository; the Repository requests information about the object from the Gateway to provide information.
Gliffy Diagram | ||||
---|---|---|---|---|
|
Restore
Flow
- The Repository manager selects an object to be restored from preservation storage
- The Repository calls the Gateway POST Object Restore endpoint for the object to be restored
- The Gateway resolves the object into a set of files to be restored
- The Gateway calls the Bridge Restore Content endpoint with the list of files to be restored
- The Bridge initiates a restore action for all files in the restore request and creates a directory in Bridge staging storage for the restored files
- The DDP calls the Bridge List Restores endpoint on a regular schedule to check for new restore requests
- The DDP copies each file in the restore request to the specified directory in Bridge staging storage
- When all files have been copied into Bridge staging storage the DDP calls the Bridge Complete Restore endpoint to inform the Bridge that the restored files are available
- The Bridge validates that all file checksums match the checksums provided in the restore request (when checksums are provided)
- The Bridge updates the status of the restore action to "STAGED_FOR_RESTORE"
- The Gateway calls the Bridge Restore Status endpoint on a regular basis to determine if the status of the restore is "STAGED_FOR_RESTORE"
- The Gateway calls the Bridge Get Restored Content endpoint for each file in the restore request and stores each file in the Gateway staging storage
- The Repository calls the Gateway Get Object endpoint and pulls the content into repository storage
- The Repository sends a notification to the Repository manager that requested the restore
Gliffy Diagram | ||||
---|---|---|---|---|
|
Notes
...
|
Audit
Flow
- The Repository manager selects an object and requests a preservation audit history
- The Repository calls the Gateway GET Object Audit endpoint for the object
- The Gateway calls the Bridge Get Audit History endpoint, specifying the object ID as the filegroup identifier
- The Bridge gathers audit data for the given filegroup and associated files from its internal data store and responds to Gateway with the requested audit history data
- The Gateway translates the Bridge audit data into a format familiar to the repository and responds to the Repository request
- The Repository displays the audit data to the Repository manager
Gliffy Diagram | ||||
---|---|---|---|---|
|