Vanochtend gaf een datacontainer bij ons de onderstaande foutmelding (itgenscr652). Het betreft een datacontainer waarop auto-recovery al aan stond en waarvan de auto-recovery gegevens nog geldig waren. De auto recovery was geconfigureerd op 16 augustus.
De foutmelding:
Error: The remote server returned an error: (500) Internal Server Error. (eol: De datacontainer moet gerepareerd worden. Vernieuw de aanmeldgegevens op de datacontainer en probeer het opnieuw. (itgenscr652, ##### )) OData Version: 4, Error: The remote server returned an error: (500) Internal Server Error. (eol: De datacontainer moet gerepareerd worden. Vernieuw de aanmeldgegevens op de datacontainer en probeer het opnieuw. (itgenscr652, #####)) OData Version: 3, Error: The remote server returned an error: (500) Internal Server Error. (eol: De datacontainer moet gerepareerd worden. Vernieuw de aanmeldgegevens op de datacontainer en probeer het opnieuw. (itgenscr652, #####))
Intussen hebben wij de autorisatiegegevens vernieuwd en werkt alles weer. Echter hebben wij nog twee vragen:
Wat is de achterliggende oorzaak van dit probleem? Dan kunnen we deze foutmelding in de toekomst voorkomen.
Hoe kan het zijn dat de auto-recovery van EOL niet heeft gewerkt?
Wat is de achterliggende oorzaak van dit probleem?
De achterliggende oorzaak is een HTTP 503 die door Exact Online teruggegeven wordt, niet op de uitwisseling van tokens, maar een check op de geldigheid van de nieuwe access token door het aanroepen van het endpoint current/Me.
Even iets achtergrond: Exact heeft een aparte manier van werken met tokens. Tokens wordt pas ‘actief’ gemeld op het moment dat er een request mee gedaan wordt. De Invantive software kan soms een token ophalen die het niet nodig blijkt te hebben. Om te checken of een token geldig is, en ook direct deze ‘actief’ te maken, wordt bij het uitwisselen van de tokens direct current/Me aangeroepen.
Hoe kan het zijn dat de auto-recovery van EOL niet heeft gewerkt?
De HTTP 503 melding komt dus niet door het uitwisselen van tokens, maar door het aanroepen van current/Me. Omdat de tokens wel geldig zijn wordt de auto recovery niet aangeroepen. De Exact API is op dat moment down geweest (misschien door een backup, het installeren van een nieuwe Exact API versie, of een interne storing, etc.). Hier zou de Invantive software beter mee om kunnen gaan. In een toekomstige versie zal de software in dit specifieke geval (een HTTP 503 bij het ophalen van current/Me) geen foutmelding meer geven.
Tot op heden krijgen wij nog steeds wekelijks deze foutmelding. De auto-recovery van EOL staat aan, maar werkt nog steeds niet. Hebben jullie zicht op wanneer Invantive software beter met de foutafhandeling van de bovenstaande foutmelding uit EOL (HTTP 503) om kan gaan?
Ik krijg voor één datacontainer de volgende foutmelding (voor OData 3 en OData 4):
Failure details:
Microsoft.Mashup.Engine1.Library.Resources.HttpResource:
Request failed:
OData Version: 3 and 4, Error:
The remote server returned an error:
(500) Internal Server Error.
(eol: De datacontainer moet gerepareerd worden. Vernieuw de aanmeldgegevens op de datacontainer en probeer het opnieuw.
(itgenscr652, d67539fa-b970-4ae9-bec0-20498897ceb2))
Er is een datacontainer gevonden met een groter aantal partities en een foutmelding onder dit abonnement:
itgenscr560: eol:
Toegang tot de OAuth-gegevensbron vereist een geldig access token.
Het access token kon niet worden verkregen.
Meld aan op Invantive Cloud en vernieuw de autorisatie op de datacontainer met alias ‘eol’ van de database ‘Exact Online BYOD John Doe’.
Deze database lijkt sinds 30-09-2022 02:04:50 (UTC) dit probleem te kennen.
De waarschijnlijke oorzaak is recent ook elders voorbijgekomen. Rond deze tijd in de nacht kan Exact Online down zijn vanwege onderhoud. Echter, de status van de Exact Online API Data Server voor de data en de Exact Online API Authenticatie Server voor het verwerven van een nieuw access en refresh token kan blijkbaar uit elkaar lopen. Dat is op zich niet erg, ware het niet dat Exact bovendien keuzes heeft gemaakt die afwijken van industriestandaarden omtrent de geldigheid van het refresh token die leiden tot beperkte recoverymogelijkheden. Meer informatie hierover is te vinden vanaf de startpagina: Exact Online foutmelding: Old refresh token used.
De afgelopen maand zien we regelmatig dat bij langduriger Exact Online downsituaties er wel een nieuw access en refresh token opgehaald kunnen worden, maar dat deze niet te activeren zijn op de API-server zelf en/of een onjuist antwoord terugkomt. Er is middels een release vorige week gepoogd het gedrag te verfijnen in de code, maar blijkbaar is dat niet afdoende en op basis van de theorie achter het Two Generals is het onzeker of dit sluitend gemaakt kan worden. Gezien de historie over deze veranderingen in 2021 en de risico’s op downsituaties door het aanpassen van het algoritme is er geen plan om dit met Exact bespreekbaar te maken.
Advies is om de downloads niet te schedulen rond de downtijden van Exact Online.
Mochten er veel administraties verwerkt worden van meerdere klanten, dan is het ook mogelijk om per klant een aparte database te registreren met een eigen app registratie (client ID) zoals beschreven in Registratie Exact Online app voor gebruik met Invantive Cloud. Dit maakt het mogelijk om eerder, deelsgewijs en sneller te verversen en het refresh token is per combinatie van client ID en Exact Online user ID.
Er zal parallel nog gekeken worden of een verdere verfijning mogelijk is, maar zoals gezegd zal hierbij een afweging gemaakt worden tussen risico’s en verbetering.