Problem: There isn't a lot of information on post-store callback in Archivematica, especially the original <source_id> post-store AIP call-back #947
Labels
API
Issues relating to the Archivematica APIs, bugs/new endpoints, etc.
Type: documentation
The issue requires documentation.
Version of the documentation
Archivematica Storage Service: 0.15.
Page (and section, if applicable) where the issue occurs
Storage service API wiki and docs themselves.
Description of the issue
The storage service supports two types of call-back. A callback is a communication to another server, following a specific trigger (the successful storage of an AIP, or explicit call to the server to repeat the message so it can be consumed if missed previously.).
The documentation around the old-style format is a little limited, and difficult to trigger. The old-style call-back is specifically
Post-store AIP (source files)
orpost_store
rather thanpost_store_<package_type>
e.g.post_store_aip
,post_store_dip
,post_store_aic
. This API endpoint is entirely for the old-style callback.Eliciting a response from the endpoint to see what we can expect...
If I create an artificial state that will help us to mimic the interaction, i.e. manually add files to the Files model for a specific AIP, then I can make an API call as follows:
If I set up a server to receive arbitrary requests, I can read the request as per below:
In this instance, the
Content
translates to JSON:If there were three files in this AIP, this would repeat three times with different file UUIDs.
The response to my original API call is:
HttpNoContent
is on the happy path in the code and so we should update the docs to say that an expected response from the server for aGET
request is a204
.If the message cannot be delivered, then the response indicates that it could not be sent.
The callback is configured as follows:
If the AIP is stored correctly then this callback is triggered. Again artificially populating the File model makes this response work for us.
Source ID translates to a UUID assigned to a specific file in an AIP per the File model.
This model is never normally populated per #342.
Suggested fix
Other things that we may consider include some sort of automated test (AMAUAT) to trigger this call for Fedora style SWORD2 ingests to make sure this works consistently with the integration. The feature file and code would provide useful reference for developers in future.
Additional information
Most of the information above is included to (hopefully) make it easier for someone looking at this in future to understand the capability of the endpoint. Some additional context is included below.
models.File
is the same that is engaged via the/v2/file/<uuid>/contents/
endpoint. The Files table is not updated for any other AIP type, which is what restricts this feature to SWORD2 (I believe).For Artefactual use:
Before you close this issue, you must check off the following:
The text was updated successfully, but these errors were encountered: