Itgeneor192/itgeneor229 Exact Online: no remaining capacity

Wij gebruiken de Invantive Data Hub om data uit Exact Online te trekken. In dit geval voor een organisatie met accountancy licentie, we halen zo’n 130 administraties tegelijk op. Zijn druk aan het ontwikkelen dus gebruiken het daarom intensief, maar krijgen sinds vanmorgen onderstaande melding. Query tool opent niet meer, en ook de load in Data Hub draait niet meer goed.

Wist niet dat er überhaupt een maximum aan de calls zat. Hoe kunnen we dit verhelpen? Zeker in ontwikkelfase gebruiken we intensief.

Exact Online gebruikt rate limits om het aantal calls per dag en per minuut te limiteren. Standaard is de limiet 300 calls per administratie per minuut (moet worden 60 calls) en 5.000 of 50.000 calls per dag per administratie, afhankelijk van afspraken.

Meer informatie hierover vind je in:

Met Data Replicator kun je gebruik maken van trickle loading voor de grote tabellen op Exact Online, zoals beschreven in bijvoorbeeld Enable webhook trickle loading on OEM licenses.

Ik vermoed dat het getal van 300 in de foutmelding incorrect is en een bug in onze software. Dit had waarschijnlijk 5.000 of 50.000 moeten zijn. Wat apart is dat het gaat om een accountancylicentie. De rate limits zijn per administratie en bij accountants komt eigenlijk nooit voor dat men de limiet overschrijdt.

Wat je nog kunt proberen is om in Exact Online een andere default administratie te kiezen. De error treedt waarschijnlijk op bij het ophalen van de lijst van administratieclassificaties en die kun je ook bij een andere administratie opvragen.

Daarna kun je in de view RateLimits meer informatie vinden. Ik raad aan om te kijken of de divisie 1796591 wel echt groot is, bijvoorbeeld miljoenen boekingen per jaar. Zo ja, dan die proberen te laden binnen de limieten die Exact hieraan stelt. Zo nee, dan is er iets anders aan de hand. Op consultbasis kunnen we eventueel hierin adviseren, maar soms is gewoon onoplosbaar. Zo kennen we in de ijzerwarenbranche de noodzaak om honderdduizenden API-calls uit te voeren binnen enkele dagen voor hun catalogus. Die passen gewoon niet zo goed bij Exact Online.

Bedankt voor reactie.

Probleem is nu dat de hele koppeling niet meer kan worden geopend in Invantive, maar ook niet via de data hub. Heb nu bijvoorbeeld de hele laadprocedure gereduceerd tot één administratie (ipv 130) maar dan klaagt ie ook dat het limiet is bereikt (voor een andere partitie). Op deze manier ligt de hele productie plat omdat er enkele partities eventueel op limiet zitten.

Tips hoe hier mee om te gaan?

P.s. hoe pas ik de default administratie aan dan? Want ik kan nu de query tool ook niet meer openen door die foutmelding.

De default administratie kan aangepast worden door op de website van Exact Online aan te melden. En dan een andere administratie te openen.

Ik vind dit wel een interessante casus. Recent is er een wijziging doorgevoerd in de Exact Online API’s om een chicken-or-the-egg probleem op te lossen specifiek voor het ophalen van gebruikersinformatie. Dit is voor division scoping. Het zou kunnen dat deze wijziging telkens alles via 1 administratie laat lopen qua API’s die Invantive SQL uitleest bij het openen van de verbinding.

Handigste is om een ticket aan te maken op support portaal en om via een beveiligde verbinding het gebruikte cliënt ID en het secret door te geven en via een aparte verbinding het refresh token. Dan kijken we of we het probleem kunnen opwekken en betrekken we eventueel de Exact Online API support.

Terzijde: gaat het om een klantspecifieke client ID of een client ID die in het Exact app center gebruikt wordt?

Het betreft een cliënt id die in het app center is geregistreerd onder onze eigen app.

Vanmorgen bij het laden van één kleine administratie al bij poging 1 de melding dat de capaciteit bereikt is. Dit kan niet kloppen want het is een kleine administratie en liep de afgelopen weken constant goed meerdere keren per dag.

Ondersteuning is gewenst om te kijken naar achterliggend probleem.

Kun je de volgende SQL eens uitvoeren in Query Tool met “Execute All” knop?

--
-- Select all Exact Online companies.
--
use all@eol

--
-- Run till an error occurs.
--
select count(*)
from   exactonlinerest..journals@eol

select distinct
       1 Division /* Division obfuscated. */
,      DailyLimit
,      DailyUsedToday
,      MinutelyLimit
,      MinutelyLastRemaining
from   ratelimits@eol
order
by     DailyLimit

Dit moet er uit komen qua gebruik van API rate limits op Exact in combinatie met een klantspecifieke client ID:

En dit komt er grofweg uit voor een client ID met 50.000 calls per dag waarbij 1 administratie er overheen gegaan is:

Het vreemde is namelijk dat de foutmelding die je aangeeft een limiet van 300 calls opgeeft. Dat is waanzinnig weinig. Meestal is 5.000 of 50.000, zoals je ook in deze voorbeelden ziet:

itgeneor229: There is no capacity remaining available for API use on partition '999'.
Please acquire more API calls per day then the current limit of 50.000 calls or try again tomorrow.

Meer tips voor het opvragen van Exact Online API usage vind je op Check and report Exact Online API usage.

Het probleem is, dat ik de query tool al niet eens kan openen. Er komt namelijk meteen een melding dat ik al aan de max van de capaciteit zit.

In dat geval is beste of wachten tot de daglimiet weer gereset wordt (vannacht) of met volgende versie proberen. Die zal in de loop van vandaag uitkomen en die zal vaak (niet altijd) wel nog kunnen aanmelden.

Geen oplossing van de sterk beperkte daglimieten, maar de laatste BETA stelt je wel in staat om meestal door het aanmeldscherm heen te komen omdat er bij een foutmelding teruggevallen kan worden op oude caches voor Exact Online administraties, administratieclassificaties, available features, abonnementinfo en accountant informatie:

Zie BETA release 20.1.326 op https://releasenotes.invantive.com/BETA/invantive-data-hub.html and https://releasenotes.invantive.com/BETA/invantive-query-tool.html.

Ik ga de nieuwe versie installeren. Dank.

Hoop uiteraard dat de oorzaak ergens wordt aangepakt (waar deze ook zit) en de limieten weer worden verhoogd of een eventuele bug of storing wordt verholpen.

In nieuwe release kun je via de view RateLimits@ALIAS in ieder geval zien hoeveel API calls je per dag per administratie met de gekozen client ID kunt uitvoeren. 300 per dag is rijkelijk weinig.

Heb nieuwe versie geïnstalleerd. Kan nu inderdaad de query tool weer openen. Ik selecteer dan boven ‘alle administraties’:

Vervolgens voer ik de query uit die jij doorgeeft. Ik krijg dit als resultaat:

Ik zie een regel met 50000 en een regel met 300 (maar in beide is er nog capaciteit volgens deze query). Ik word hier dus nog veel wijzer van.

Is dit wat je zou verwachten of gaat hier iets niet goed?

Heel bijzondere cijfers! De daglimieten zijn niet overschreden maar blijkbaar heeft een deel van de administraties een heel lage daglimiet van 300 en een deel een limiet van 50.000. Je kunt eventueel nog een group by op de maximum dag limiet toevoegen om te zien hoeveel van de 441 administraties in welke groep zitten. Maar long story: dit is echt iets voor Exact Online API Support.

Reactie van Exact. Dit had natuurlijk van tevoren aangekondigd moeten worden en hierdoor zitten we nu in de shit bij omgevingen die live waren:


EXACT:

Ik heb hier intern contact over gehad. Het gaat om de app met naam ‘BI voor Accountancy’. Er is een beslissing gemaakt om het limiet van deze app te verlagen, vanwege de hoeveelheid data die dagelijks wordt gedownload dat een negatief effect heeft op onze performance.

Het limiet was inderdaad verlaagd naar 300 en dit heb ik met overleg kunnen laten verhogen naar 1000. Dus per divisie kun je 1000 calls maken. En je zal nu aan het werk moeten gaan om de app efficienter te maken. Dat betekent o.a. niet dagelijks dezelfde data downloaden. Exact heeft de afgelopen tijd meer endpoints ontwikkeld, waardoor het mogelijk is om alleen nieuwe en gewijzigde data op te halen.

Even als voorbeeld. We zien bijvoorbeeld elke dag opnieuw veel calls op het endpoint GLClassifications. Van dit endpoint is een bulk endpoint, dat nog niet door jullie wordt gebruikt, maar waar je wel veel calls mee kunt besparen. Tevens is hier een sync endpoint van, waarmee je de gewijzigde data kunt ophalen. Dus genoeg mogelijkheid om dit efficienter te bouwen.

En op deze manier moet je dus kritisch kijken naar hoe de app de data ophaalt en of dat beter kan. Graag wil ik dan een afspraak met jullie maken, wanneer jullie dit aangepast kunnen hebben. Tot die tijd zal die 1000 calls blijven gelden.

Mocht je nog vragen hebben, dan hoor ik dat graag.

Helemaal mee eens. Wij zullen een klacht gaan indienen bij Exact.

Hmm, dat is geen handige actie, mevrouw Maxima van Oranje zou dat anders benoemen.

Tabel GLClassifications

Ik kan me niet voorstellen dat GLClassifications versus GLClassificationsBulk enorm verschilt maakt; dat zijn misschien 5-10 API calls per administratie per dag voor een Nederlandse omgeving. In Belgie meer met het grote standaardschema in Belgie.

Advies

Ik begrijp dat meerdere OEM-partners in meerdere landen hierdoor nu down zijn, terwijl klanten met jaarwerk 2020 bezig moeten.

Advies is om een klacht in te dienen bij Exact support en eventueel eindklanten die erg veel hinder ervaren in hun werkzaamheden dit ook gemotiveerd te laten doen, eventueel bij hun accountmanager. Een klacht indienen doe je door een apart ticket te maken en hierin duidelijk te vermelden dat het een klacht is.

Mijn advies is met klem te verzoeken een redelijke termijn te geven om de configuratie te laten omzetten, zorgvuldig testen en dan pas live gang, hierbij rekening houdend met het jaarwerk bij de betrokken bedrijven. Het gaat volgens onze metingen om tenminste honderden administraties die nu geen actuele cijfers hebben, voornamelijk stichtingen en de top 3% qua omzet van de gebruikers op Exact. Ik zou zelf 4 weken een ondergrens vinden.

Zonder communicatie vooraf limieten veranderen is niet handig. Ik was onder de indruk dat er afspraken lagen tussen Exact en de developer community om niet eenzijdig en zonder terugkoppeling of vooraankondiging zaken aan te passen. Als echt het hard nodig is, moet je als SaaS-leverancier altijd eenzijdig iemand kunnen afsluiten, maar breed en zonder enige vorm terugkoppeling vind ik niet netjes en commercieel onhandig.

Workarounds

In de tussentijd kun je kijken of trickle loading een alternatief biedt. Kijk eerst in het scherm “Session I/Os” welke tabellen gebruikt worden. Dat zal ook in de scripts terug te vinden zijn. Voor een aantal tabellen zijn er ook webhooks die je kunt gebruiken met trickle loading:

Echter, merk op dat de inhoud van de tabellen via trickle loading NIET gegarandeerd hetzelfde is. Wijzigingen in de basistabellen van afgeleide velden zoals JournalCode en JournalDescription worden niet gereflecteerd in de replica’s. Rapportages dienen het genormaliseerde datamodel te gebruiken.

Indien assistentie hierbij nodig is, dan kan die gepland worden via https://go.invantive.com/book/consult.

Telling geeft aan dat het gaat om maximaal 760 administraties in verschillende landen die geraakt zijn door deze aanpassing. Het is maar een klein percentage van alle administraties die geraakt worden, maar vooral de grootste Exact gebruikers zijn hierin vertegenwoordigd.

Inmiddels zijn door Exact een aantal wijzigingen doorgevoerd om de impact te verkleinen. Circa 10 administraties op pakweg 5 abonnementen zijn nog betrokken. Gelieve hiervoor de boven beschreven stappen te volgen bij “Workarounds”.