Acknowledgement processing
Datahub acknowledges requests of parties on two levels: technical and process level. On the technical level, the Datahub interface always responds to each request by a party communicating whether the request was understood and received in its entirety, or not. This is the interface’s so-called technical acknowledgement, which is separate from, e.g., the process level business acknowledgements presented in the sequence diagrams. Technical acknowledgements are not part of our sequence diagrams.
Datahub delivers a positive or negative acknowledgement to all received messages on the process level too. In data retrieval events the retrieved data serves as a positive acknowledgement. In error situations, a negative acknowledgement is returned. Errors found in the process and event validations described in Message validations are reported in a negative acknowledgement. For synchronous services, the process level acknowledgement is returned to the party when Datahub has processed the request in its entirety. For asynchronous services, Datahub first returns a technical acknowledgement of accepting the request and later an asynchronous process level acknowledgement of processing the event. Asynchronous services are described in more detail under Event synchronicity/asynchronicity. In Datahub’s acknowledgement messages, message header data never specifies whether an acknowledgement is wanted or not.
When retrieving messages, the party retrieving them from Datahub should acknowledge receipt of the messages as described under Request event.
Datahub uses an acknowledgement message based on the ebIX structure. It includes header, process and acknowledgement event. In terms of content, a message’s process element is the same as in the original message to be acknowledged. The content of an acknowledgement event is as follows:
Data field | Level | Necessity | Note |
|---|---|---|---|
Acknowledgement event | 1 | 1..1 |
|
Acknowledgement type | 2 | 1..1 |
The acknowledgement type ‘partially approved’ is used in metering data messages when Datahub is receiving metering data. A rejected time series is reported in the acknowledgment for the time series. When retrieving metering data from Datahub, this type of acknowledgement is not used. |
Acknowledgement of event level | 2 | 0..n |
|
Event acknowledgement code | 3 | 1..1 | Event acknowledgement or an error code, if the event is not accepted. |
Event acknowledgement text | 3 | 1..1 | Event acknowledgement or an error code, if the event is not accepted. Also used in a positive acknowledgement to report the type of update in Datahub. For example, when acknowledging a sales agreement, the reason for the sales agreement start that Datahub determines (switching agreement, switching supplier, moving in) is returned in the ‘Event details’ field. |
Event details | 3 | 0..n | Also used in a positive acknowledgement to report the type of update in Datahub. For example, when acknowledging a sales agreement, the reason for the sales agreement start that Datahub determines (switching agreement, switching supplier, moving in) is returned in the ‘Event details’ field. |
Series data | 2 | 0..n | If the acknowledgement type is ‘Partially approved’, series data will list the series rejected. Each series can contain multiple different acknowledgement types that will be listed under the acknowledgement of the series. |
Sender’s series ID | 3 | 0..1 |
|
Series UID | 3 | 1..1 |
|
Acknowledgement of series | 3 | 1..n | If the acknowledgement type is ‘Partially approved’, series data will list the series rejected. Each series can contain multiple different acknowledgement types that will be listed under the acknowledgement of the series. |
Series acknowledgement type | 4 | 1..1 |
|
Series acknowledgement text | 4 | 1..1 |
|
Series details | 4 | 0..n |
|
The technical description of the acknowledgement message can be found under ACK Acknowledgement event.