Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Gliffy Diagram
namedeposit_content
pagePin89

Delete

Flow

  1. The Repository manager selects an object to be deleted from preservation storage
  2. The Repository calls the Gateway DELETE Object endpoint for the object to be deleted
  3. The Gateway resolves the object into a set of files to be deleted
  4. The Gateway calls the Bridge Delete Content endpoint with the list of files to be deleted
  5. The Bridge initiates a delete action for all files in the delete request
  6. The DDP calls the Bridge List Deletes endpoint on a regular schedule to check for new delete requests
  7. 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
  8. 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
namedelete_workflow
pagePin34

Restore

Flow

  1. The Repository manager selects an object to be restored from preservation storage
  2. The Repository calls the Gateway POST Object Restore endpoint for the object to be restored
  3. The Gateway resolves the object into a set of files to be restored
  4. The Gateway calls the Bridge Restore Content endpoint with the list of files to be restored
  5. 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
  6. The DDP calls the Bridge List Restores endpoint on a regular schedule to check for new restore requests
  7. The DDP copies each file in the restore request to the specified directory in Bridge staging storage
  8. 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
  9. The Bridge validates that all file checksums match the checksums provided in the restore request (when checksums are provided)
  10. The Bridge updates the status of the restore action to "STAGED_FOR_RESTORE"
  11. The Gateway calls the Bridge Restore Status endpoint on a regular basis to determine if the status of the restore is "STAGED_FOR_RESTORE"
  12. 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
  13. The Repository calls the Gateway Get Object endpoint and pulls the content into repository storage
  14. The Repository sends a notification to the Repository manager that requested the restore

Gliffy Diagram
namerestore_workflow
pagePin24

Audit

Flow

  1. The Repository manager selects an object and requests a preservation audit history
  2. The Repository calls the Gateway GET Object Audit endpoint for the object
  3. The Gateway calls the Bridge Get Audit History endpoint, specifying the object ID as the filegroup identifier
  4. 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
  5. The Gateway translates the Bridge audit data into a format familiar to the repository and responds to the Repository request
  6. The Repository displays the audit data to the Repository manager

...