This clause defines the method by which a Release Creator can provide Batches of metadata and Resource files to a Release Distributor via (i) an SFTP server that is hosted by the Release Creator, (ii) an SFTP server that is hosted by the Release Distributor, (iii) an SFTP server that is hosted by a third party or (iv) a hard disk that is populated by/on behalf of the Release Creator and then shipped to the Release Distributor. This specification does not therefore define on whose hardware the files are being stored. This is for the Release Creator and the Release Distributor to agree.
The choreography of the FTP Batch Profile is as depicted below:
Release Creator and Release Distributor may agree, on a bilateral basis other online delivery mechanisms for the Resource files.
The trigger to indicate that a Batch is complete is a
ManifestMessage as defined in Clause 10 of this standard. In exceptional circumstances, such as for the support of human intervention, it is permissible to use a zero-byte semaphore file to indicate the upload is complete. This semaphore file has to be used instead of an XML manifest formatted in accordance with Clause 10. The use of such a semaphore file may trigger a flag on the Release Distributor's side, indicating the manual nature of the override. The message is also depicted below.
The structure of the
NewReleaseMessages communicated in this profile shall follow the Release and Business Profiles agreed as appropriate for the communicated Release(s).
The structure and file naming conventions for the FTP Release-by-Release Profile are defined in Clauses and of this standard.
This standard does not define when the Release Creator shall start or finish to upload the next
NewReleaseMessage (including all Resource files). Equally, this standard does not define when the Release Distributor shall start or finish its download.
In addition to the exchanged shown in the diagram above, the recipient of the
NewReleaseMessage may use the same message for subsequent status updates (e.g. when, after reporting
FileOK after ingestion, closer inspection shows deficiencies that were not detected previously.
The recipient of the
ErnAcknowledgementStatusMessage may remove an
ErnAcknowledgementStatusMessage from the FTP server after an appropriate and mutually agreed period of time. The default period is one month.