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:

  1. commonTechnical; contains among other things the identification of the message exchange platform provider, the sender of the container, date and time of creation. The commonTechnical is always mandatory within a container structure.
  2. 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"
		} ]
}

Feedback

Thanks for your feedback.

Post your comment on this topic.

Please do not use this for support questions.
If you have any support questions, do not hesitate to contact us.

Post Comment