Function: submitContainer

This function allows a message exchange platform client (PO box owner) to send messages to other message exchange platform clients. The message exchange platform client gathers a selection of messages to be put in a container. There are no restrictions to the type of message. All messages in one container have to be from the same sender, the receiver may vary per message.

Usage: submitContainer

The function can be used by a message exchange platform client to deliver a container with messages to the platform, or by the message platform provider to deliver the content of the client PO box to an API offered by the client for this purpose. The first option can also be used by a message exchange platform to forward messages destined for other message exchange platforms in case of a roaming agreement (see also: roaming).

# Variant Description
1 client A client sending messages in a container to the message exchange platform (MEP).
2 deliver The message exchange platform sending messages in a container to a client.
3 roaming The message exchange platform sending messages in a container to another MEP.

Client

With the client variant, a submitted container may contain messages for any receiver subscribing to any platform, and the sender will be the party that submits the container with messages to the platform. This is the regular variant of the submitContainer function which is always provided by the message exchange platform provider to the message exchange platform clients.

Deliver

In this variant all messages in the container will have the same receiver, which is the message exchange platform client who provides an API to receive his messages.
Much like a physical PO box, in the electronic variant the owner of a PO box has to actively check for incoming messages. In case of a demand for near-real-time response, a high frequency of polling causes a lot of unnecessary network traffic and handling.
The deliver variant can be provided as a service from the message exchange platform. It gathers incoming messages at regular intervals and places them in a container. This container is then sent with the submitContainer function to the API that is provided by the message exchange platform client. With this option the message exchange platform client no longer needs to poll his PO box to check for incoming messages.
The deliver variant of submitContainer is the active form (push) of the request container variant (pull), and the processing and subsequent actions are the same. After successful processing the confirm variant of the changeContainer function can be used. In case of a processing failure the cancel variant of the changeContainer function applies. Please refer to the changeContainer section for further information.

Roaming

The roaming variant can be provided as a service from the message exchange platform. It gathers incoming messages destined for other message exchange platforms and places them in a container. This container is then sent with the submitContainer function to the API of the destined message exchange platform. In case of roaming there can be different senders and different receivers for messages within the same container, but they will all have the same mepId.

If a message cannot be distributed, for instance if the receiver is not known on the message exchange platform, a copy of the meta-data from the message is added to the response. This enables the sender of the container to investigate the reason why delivery on the message exchange platform failed, and to take measures to correct the situation.

Technical specifications: submitContainer

Input: submitContainer

Name Variant Type Description
container Collection of individual messages, transported to or from a message exchange platform (MEP)
commonTechnical General entity for process/handling support.
entityType all string Set to ‘default’.
mepId all string The unique registration/identification issued by SIVI, to identify a message exchange platform (MEP).
senderId all string The unique identification on the message exchange platform of the party that submits a container to the platform.
externalReference all string A (unique) container reference from the party that submits a container.
creationDate all date Date of the creation of the container.
creationTime all date Time of the creation of the container.
hashType all APIHSH The algorithm that is used to calculate the hash total.
hashTotal all number The hash total of the messages object content, calculated according to the algorithm that is defined in the hashType attribute.
commonFunctional Entity for general information with regard to structure, handling and processing.
entityType all string Set to ‘default’.
functionVariant all APIVAR The function variant is used to determine the additional set of required and optional input and output data.
messages array A set of messages sent in a container (see message structure for more details).

Output: submitContainer

Name Variant Type Description
container Collection of individual messages, transported to or from a message exchange platform (MEP)
commonTechnical General entity for process/handling support.
entityType all string Set to ‘default’.
containerId all string The unique registration/identification of the container on a message exchange platform.
mepId all string The unique registration/identification issued by SIVI, to identify a message exchange platform (MEP).
externalReference all string A (unique) container reference from the party that submits a container.
containerStatus all APICST Indication of the new status (input) or present status (output) of the container.
commonFunctional Entity for general information with regard to structure, handling and processing.
entityType all string Set to ‘default’.
functionVariant all APIVAR The function variant is used to determine the additional set of required and optional input and output data.
error [ ] Entity for error handling and support.
entityType all string Set to ‘default’.
errorCode all AFDERR Error code.
errorDescription all string Description of the error.
message A copy of the meta-data from a message in a container which could not be distributed or retracted.

Errors

When a negative response is generated, it follows the general rules as described in the Error section of the Status codes and error handling chapter.

Click below to see the Open Api Specification (3.0.0)

Feedback

Thanks for your feedback.

Post your comment on this topic.

Post Comment