General properties
Data can be exchanged in a synchronous or asynchronous manner, depending on specific processes and circumstances. The most common methods for asynchronous exchange are via File Transfer Protocol and message exchange platforms (MEP), often used in bulk processes. In order to avoid overhead when transporting individual messages, the containerStructure
offers the possibility to transport a set of messages.
Mandatory components
In a way, the containerStructure
differs from the usual setup for structures. At the highest level, no separate container entity is visible within the message (such entity does not exist). Instead, the container-related attributes are all in the mandatory commonTechnical
entity.
As mentioned, the containerStructure
also offers the possibility to send a set of messages at once. For these messages it is possible to repeatedly include the document entity (if desired), also at the highest level. Because both functional and technical metadata can vary per message, it is possible at the top level to include multiple commonTechnical
and commonFunctional
entities that refer (through documentRef
) to the appropriate instances of the document entity. See the example at the bottom of this page for clarification.
As mentioned, (at least) the container-related metadata should be reflected in the commonFunctional
and commonTechnical
at the top level:
commonTechnical
; contains among other things the identification of the message exchange platform provider, the sender of the container, date and time of creation. ThecommonTechnical
is always mandatory within acontainer
structure.commonFunctional
; a set of fields that can be used for the routing and handling/workflow of the container without the need to consult the content.
The table below contains the mandatory entities and attributes of the container
. Please note: these are only the mandatory components. When (a set of) messages are sent along with the containerStructure
, the document
entity is also mandatory. Please note: the attributes listed here as mandatory under commonFunctional
and commonTechnical
are mandatory only once. When also including commonTechnical
and commonFunctional
entities that refer to specific document entities, the container-related attributes are not required.
More documentation on the use of SIVI AFS is available in chapter Where to find elements of SIVI elements. A general description of AFD structures is provided in Introduction to AFD structures, while information on details of AFD structures is available in chapter Where to find details about AFD structures.
Name | Occur. | Type | Description |
---|---|---|---|
containerStructure | 1..1 | entity | Collection of individual messages, transported to or from a message exchange platform (MEP). |
commonTechnical | 1..n | entity | Covers all information about sending or storing the message. |
entityType | 1..1 | string | Set to ‘default’. |
containerId | 1..1 | string | Unique registration of the container on the Message Exchange Platform. |
senderId | 1..1 | string | Technical reference to the sender of the message. |
containerStatus | 1..1 | APICST | Indication of the new status (input) or present status (output) of the container. |
creationDate | 1..1 | date | Creation date of the (for example) message, system or file. |
creationTime | 1..1 | time | Creation time of the (for example) message, system or file. |
commonFunctional | 1..n | entity | Entity for general information with regard to structure, handling and processing. |
entityType | 1..1 | string | Set to ‘default’. |
functionVariant | 1..1 | string | The function variant is used to determine the additional set of required and optional input and output data. |
JSON example
This example shows how to set up a containerStructure
with two messages (message1 and message2), and combine it with multiple top-level commonTechnical
and commonFunctional
entities. The first commonTechnical
and commonFunctional
define the container, the second commonTechnical
and commonFunctional
– as you can deduct from the documentRef
– relate to both messages. Note that at the top level within JSON, the containerStructure
entity is not explicitly mentioned. In XML, the structure is always explicitly defined (as containerStructure
) at the highest level.
{
"commonTechnical": [ {
"entityType": "default",
"containerId": "c4eef3a3-8f6d-440b-8b34-8b785fa1301f",
"mepId": "MEP2020",
"senderId": "I095678905678901",
"recipientId": "A610895101792",
"containerStatus": "Submitted",
"creationDate": "2020-01-01",
"creationTime": "08:00:00",
"hashType": "04",
"hash": "12345678"
},
{
"entityType": "default",
"messageId": "c4eef3a3-8f6d-440b-8b34-8b785fa1301f",
"documentRef": ["message1", "message2"],
"mepId": "MEP2020",
"senderAliasType": "05",
"senderAlias": "poBox",
"senderId": "I095678905678901",
"receiverAliasType": "05",
"receiverAlias": "poBox",
"receiverId": "I095678905678901",
"creationDate": "2020-01-01",
"creationTime": "08:00:00"
} ],
"commonFunctional": [ {
"entityType": "default",
"functionVariant": "A0520",
},
{
"entityType": "default",
"documentRef": ["message1", "message2"],
"dataCatalogType": "AFD",
"dataCatalogVersion": "35C",
"messageSubject": "1",
"messageContext": "200",
"messageFunction": "2000"
} ],
"document": [ {
"entityType": "default",
"refKey": "message1",
"contentEncoding": "base64",
"contentType": "text/xml; charset=cp858",
"fileName": "afd001.xml",
"fileExtension": "xml",
"content": "VGhpcyBpcyBhIGJhc2U2NCBlbmNvZGVkIGV4YW1wbGUg"
},
{
"entityType": "default",
"refKey": "message2",
"contentEncoding": "base64",
"contentType": "text/xml; charset=cp858",
"fileName": "afd002.xml",
"fileExtension": "xml",
"content": "fgE31zBpcyBhIGJhc2U2NCBlbmNvZGVkIGV4YW1wbGUg"
} ]
}
Post your comment on this topic.