| Table of Contents | ||
|---|---|---|
|
Overzicht foutmeldingen
Foutmeldingen die je ontvangen hebt tijdens het verwerken kan je terugvinden via de self-service pagina https://prod.notificaties.vlaanderen.be/ of via het antwoord dat je terugkrijgt van het aangesproken endpoint. In dat antwoord krijg je een beschrijving (“description”) en een detailoverzicht van alle gevonden foutmeldingen (“errors“).
Voorbeeld:
| Code Block | ||
|---|---|---|
| ||
{
"code" : "2001",
"message" : "Validatiefouten",
"description" : "Er heeft zich een foutmelding voorgedaan. Gelieve contact op te nemen met het Notificatie team.",
"errors" : [ { "code" : "1100", "message" : "Maximum lengte voor body overschreden (80 KB).", "description" : "De maximum grootte voor een body is 80 KB.", "field" : "SleutelWaardeParen[0].Waarde" }
]
} |
HTTP 401
Er is geen of geen geldig token in de Authorization Header, zie Beveiliging DOSIS via ACM/IDM. Vraag een token aan met
scope dv_dosis_import
de juiste “audience”
audiencevoor de omgeving, ziehttps://authenticatie.vlaanderen.be/docs/beveiligen-van-api/oauth-rest/rest-server2server/aanvraag-access-token/
Deze fout komt soms voor omdat eenzelfde token te lang gebruikt wordt. Zie ook: Performantietips.
HTTP 403
De ACM-client heeft niet de nodige rechten om het dossier of de toelating aan te passen. Deze rechten worden toegekend door het Aansluitingen-team tijdens het aansluitingsproces:.
De dossierbron (met Bron-URI en Bron-ID) moet aangemaakt zijn voor de Afzender (= inhoudelijk verantwoordelijke) van de dossier- en toelatingupdatestoelatingsupdates
De ACM-client van de Aanbieder (= technisch verantwoordelijke) van v(an de updates moet de juiste rechten hebben en gekend zijn als Aanbieder voor de bron
...
Zodra de aansluitingsgegevens aangepast zijn, kan deze update onveranderd opnieuw worden aangeboden.
...
De inhoud van de notificatie voldoet niet aan de vormvoorschriften. De respons ziet er als volgt uit:
| Code Block | ||
|---|---|---|
| ||
{
"code": "string",
"message": "string",
"description": "string",
"errors": [
{
"code": "string",
"message": "string",
"description": "string",
"field": "string"
}
]
} | ||
| Info | ||
Errors is optioneel en enkel aanwezig als er meer gedetailleerde validatieboodschappen zijn. |
De message- en description-velden geven aan wat er fout was. De dossier- of toelating-update toelatingsupdate wordt niet aanvaard met de huidige inhoud.
| Info |
|---|
|
HTTP 429
De DOSIS-API wordt beschermd door een application firewall. Zodra er teveel te veel calls tegelijk komen, geeft dit de foutboodschap : HTTP 429 - Too many requests. Open uw Circuitbreaker en probeer het later opnieuw.
De huidige limiet is 1800 oproepen per minuut, voor alle gebruikers van de API. Het is dus ook mogelijk dat u deze fout ziet omdat andere gebruiker(s) een groot aantal oproepen doen.
Krijgt u deze fout frequent, neem contact op met de Servicedesk of kom langs op het technisch spreekuur, wekelijks op dinsdag van 13:00 tot 14:00 uur. De limiet moet misschien verhoogd worden of er bestaat een betere aanpak om grote aantallen statusupdates te versturen. Zie ook de performantietips Performantietips hieronder.
Performantietips
...
| Info |
|---|
Gebruik het token niet tot het laatste moment omdat het ongeldig wordt tussen het moment dat het wordt opgestuurd en gevalideerd wordt. Dat leidt af en toe tot onverwachte HTTP 401 responses. |
...
Stuur updates bij voorkeur sequentieel wanneer:
de API trager is door hoge belasting, dan stuurt u ook trager notificaties updates door
een token gevalideerd moet worden, dan zijn alle andere oproepen met hetzelfde token geblokkeerd tot het resultaat van de validatie gekend is
u de bandbreedte en de verwerkingskracht deelt met alle andere aanbieders van DOSIS. Zie ook de HTTP 429 respons als er teveel notificaties tegelijk aangeboden worden
Een update aanbieden kost meestal minder dan 1 -2sof 2 seconden. Uitzonderlijk kan duurt het langer duren, door factoren die niet altijd onder controle zijn van buiten de DOSIS-bouwsteen om, zoals de huidige belasting en de respons tijden responstijden van andere systemen die worden opgeroepen worden door DOSIS. Gebruik een communicatie timeout communicatietime-out die voldoende lang is om met dergelijke schommelingen om te kunnen. Typisch Dit is typisch een timeout time-out van 15 -30stot 30 seconden.
Wees klaar om Stuur een update opnieuw te versturen indien als het de eerste keer niet lukt omdat er een fout, timeout time-out of HTTP 429 respons komt. Dit kan bvb bijv. door deze de gefaalde updates in een queue te plaatsen en later opnieuw te proberen.
Bij een HTTP 400 validatiefout respons heeft het geen zin om opnieuw te proberen verzenden zonder eerst de inhoud van de update aan te passen. Let wel:
| Note |
|---|
|
...
|
...
|
...
|