...
Der bliver foretager flere valideringer når en forespørgsel håndteres af DataHub. Hver af disse valideringer kan resultere i forskellige fejl koder.
HTTP kode | Navn | Beskrivelse |
400 | Bad Request | DataHub kan ikke gennemføre forespørgslen |
401 | Unauthorized | Der er ikke sendt et gyldigt bearer token |
403 | Forbidden | Det medsendte token er ikke gyldigt til den pågældende adresse |
413 | Payload Too Large | Dokumentet er for stort |
415 | Unsupported Media Type | Hvis den medsendte Content-Type ikke er godkendt |
Hvis der er en fejl ved forespørgslen, bliver fejlen beskrevet ved hjælp af en ”fejl” datastruktur.
Se nedenstående tabeller. Strukturen kan returneres enten som XML eller JSON alt efter hvad klienten har indikeret i Accept header feltet. Hvis feltet ikke er medsendt, vil der som standard blive svaret i JSON.
Attribut | Type | Påkrævet | Beskrivelse |
error | Error | Ja | Objekt der beskriver fejlen |
ErrorResponse : object
Attribut | Type | Påkrævet | Beskrivelse |
code | String | Ja | Fejlkode der entydigt identificere fejlen |
message | String | Ja | Fejltekst |
target | String | Nej | Felt navn der har fejlet validering |
details | Error[] | Nej | En liste af fejl der kan uddybe hvad der er fejlet |
innererror | InnerError | Nej | Et objekt der beskriver i flere detaljer hvad der er fejlet |
Error : object
Attribut | Type | Påkrævet | Beskrivelse |
code | String | Nej | Fejlkode |
innererror | InnerError | Nej | Mulighed for at inkludere underligende fejl |
custom-attribut | Any | Nej | Eventuelle attributter der ikke er defineret i dette dokument |
InnerError : object
Eksempel (JSON) | Eksempel (XML) |
{ ”code”: ”BadArgument”, ”message”: ”Message-id previously used”, ”innererror”: { ”code”: ”MessageIdPreviousUsed”, ”message-id”: ”gs8u033bqn”, ”used-on”: ”2018-05-16T15:32:12Z” } } } | <Error> <Code>BadArgument</Code> <Message>Message-id previously used</Message> <InnerError> <Code>MessageIdPreviousUsed</Code> <Message-id>gs8u033bqn</Message-Id> <Used-on>2018-05-16T15:32:12Z</Used-on> </InnerError> </Error>
|
2.4 HTTP endpoints
Der udstilles en adresse til hvert af de dokumenttyper man kan udveksle med DataHub.
HTTP verb | RSM | Path |
POST | 001 | /v1.0/cim/requestchangeofsupplier |
POST | 003 | /v1.0/cim/requestreallocatechangeofsupplier |
POST | 003 | /v1.0/cim/confirmreallocatechangeofsupplier |
POST | 003 | /v1.0/cim/rejectreallocatechangeofsupplier |
POST | 005 | /v1.0/cim/requestendofsupply |
POST | 006 | /v1.0/cim/requestaccountingpointcharacteristics |
POST | 012 | /v1.0/cim/notifyvalidatedmeasuredata |
POST | 015 | /v1.0/cim/requestvalidatedmeasuredata |
POST | 016 | /v1.0/cim/requestaggregatedmeasuredata |
POST | 017 | /v1.0/cim/requestwholesalesettlement |
POST | 020 | /v1.0/cim/requestservice |
POST | 021 | /v1.0/cim/requestchangeofaccountingpointcharacteristics |
POST | 024 | /v1.0/cim/requestcancellation |
POST | 027 | /v1.0/cim/requestchangecustomercharacteristics |
POST | 028 | /v1.0/cim/characteristicsofacustomeratanap |
POST | 030 | /v1.0/cim/requestchangebillingmasterdata |
POST | 032 | /v1.0/cim/requestbillingmasterdata |
POST | 033 | /v1.0/cim/requestchangeofpricelist [1] |
POST | 035 | /v1.0/cim/requestpricelist |
DELETE | n/a | /v1.0/cim/dequeue/{id-of-message} [2] |
GET | n/a | /v1.0/cim/aggregations |
GET | n/a | /v1.0/cim/all |
GET | n/a | /v1.0/cim/masterdata |
GET | n/a | /ping |
2.5 Identifikation af besked type
For at hente et dokument fra DataHub sker det via en GET-kanal. Hver kanal kan returnere én eller flere dokumenttyper. Den pågældende dokumenttype kan læses fra http-headeren MessageType. For en komplet liste af dokumenttyper der kan modtages, kan dette ses i appendix – Dokumenter og deres relation til kø’er
2.6 Azure B2C – Oauth
...
HTTP-kaldets body skal bestå af følgende key-value pairs.
Key | Value |
grant_type | client_credentials |
client_id | <aktørspecifikt ID der udleveres af Energinet> |
scope | 65877f1b-1aef-42b3-adc7-3009608f27a3/.default |
client_secret | <aktørspecifik kode der udleveres af Energinet> |
Positiv tilbagemelding:
{
...