Standards:IG file.sequence
Elle n'a donc aucune valeur normative, et pourrait même disparaître du périmètre de SEPAmail.
Si vous voulez contribuer, utilisez la page de discussion SVP. Consultez également les autres pages en discussion.<svnig source="FilSeq_Intro.txt" repository="General" revision="" date="" last="" conversion="none">
Introduction
The "sequence file" structure is designed to carry various types of contents, in a strictly "intra-IS" environment. It may be considered as a replacement for the missive, when high-level security is unnecessary : no signing and no ciphering are associated with it.
This generic file contains one or several "generic elements", which must all be of the same "type" (all pain.001 for instance) and "version" (001.03 for instance, if we are considering pain.001).
This file holds a sequence number, which must be attributed in strictly ascending order. This allows the other party to check that no file is forgotten in the handling, and that it properly handles everything generated by Sepamail.
The structure also allows for an acknowledgement mechanism, which is currently not used. </svnig>
<svnig source="FilSeq_Abstract.txt" repository="General" revision="" date="" last="" conversion="none">
Internal abstraction level
To facilitate upgrades, an abstraction level has been inserted at the root of this element.
The actual contents of the SequencedFile element must be any one of the sepamail_sequenced_file_xxx structures. </svnig>
<svnig source="FilSeq_Abstract.tab" repository="General" revision="" date="" last="" conversion="tab">
| Mult | Message Element | Sepamail requirement |
|---|---|---|
| [1..1] | sepamail_sequenced_file_001 | First version of the structure |
</svnig>
<svnig source="FilSeq_Body.txt" repository="General" revision="" date="" last="" conversion="none">
Message Body
</svnig>
<svnig source="FilSeq_Body.tab" repository="General" revision="" date="" last="" conversion="tab">
| Ref | Mult | Message Element | Sepamail requirement |
|---|---|---|---|
| A | [1..1] | + SeqFile | |
| A1 | [1..1] | ++ DatTim | Date and time of creation, in ISO format |
| A2 | [1..1] | ++ Partner | Designates the communicating party, either sender or receiver, always by a BIC |
| A2.1 | {Or | +++ Sender | If this file is created by Sepamail |
| A2.2 | Or} | +++ Receiver | If this file is sent to Sepamail |
| A3 | [1..1] | ++ EltType | The exact type of the elements held in this file. Can be a string ("pain.001" for instance) or a URI. |
| A4 | [1..1] | ++ Version | The precise version of the elements, allowing schema selection for validation of the body (if needed) |
| A5 | [1..1] | ++ SeqNbr | Sequence number of the file. This must be strictly ascending, to allow for detection of any transmission or handling anomaly |
| A6 | [1..1] | ++ NbElts | Number of elements in the current file, must be a strictly positive integer. |
| A7 | [1..1] | ++ Elements | Holds the Actual payload of the file |
| A7.1 | [1..n] | +++ Element | One such item for each content. |
| A7.1.1 | [1..1] | ++++ EltId | Element identifier. Can be any string, but must be unique with a given partner. |
| A7.1.2 | {Or | ++++ EltBody | The element itself, which can be of any type |
| A7.1.3 | Or} | ++++ EltAck | Acknowledgement of the element with the given identifier. This acknowledgement can be positive (true) or negative (false). CURRENTLY, THIS FIELD IS NOT USED. |
</svnig>
<svnig source="FilSeq_Use.txt" repository="General" revision="" date="" last="" conversion="none">
Usage
This belongs anywhere but here ...
For every party using this structure, a folder will be created in a suitable place. This folder will hold two subfolders : "In" and "Out", used to held files sent to (resp. generated by) the Sepamail system.
No empty file will ever be generated. The "Out" folder will be empty if no outgoing elements exist.
The frequency of file generation will be freely determined between the communicating parties.
If an acknowledgement is generated by the external party, the files will be created in the "In" folder.
Sepamail will archive the files found in the "In" folder, but it is of the other party's responsibility to archive the files generated by Sepamail in the "Out" folder.
The file name, whether incoming or outgoing, is defined by the following grammar :
<in_file_name> ::= <date_time> '_' <sender_BIC> '.in.xml' <out_file_name> ::= <date_time> '_' <receiver_BIC> '.out.xml' <date_time> ::= <long_date> <short_time> <long_date> ::= <year> <month> <day> <short_time> ::= <hours> <minutes> <year> ::= <digit> <digit> <digit> <digit> <month> ::= <digit> <digit> <day> ::= <digit> <digit> <hours> ::= <digit> <digit> <minutes> ::= <digit> <digit> <digit> ::= '0' .. '9' <sender_BIC> ::= <BIC> <receiver_BIC> ::= <BIC>
The BIC syntax is precisely described in ISO 9362:1994.
</svnig>