Vorige week met behulp van Invantive Consultancy Trickle Loading aangezet en ingericht voor een data download vanuit Exact Online (ongeveer 160 administraties). Sindsdien wordt maar een zeer beperkte set van de data opgehaald. Bijvoorbeeld:
Voor AccountsBulk worden maar 22 partities opgehaald i.p.v. 160
Voor TransactionlinesBulk worden maar 46 partities opgehaald i.p.v. 160
Voor andere tabellen geldt hetzelfde
Lijkt erop dat misschien alleen de wijzigingen worden opgehaald? Is een eerste ingeving. In ieder geval hoort er voor 160 administraties data te laden (wat wel gebeurde voor trickle loading) maar is nu niet het geval.
Voor klant is dit zoveelste week op rij dat data niet goed geladen wordt. Bezitten nu weer geen recente data en dat begint logischerwijs voor irritatie te zorgen bij de klant.
Kan iemand van Invantive diagnose stellen van wat er na de consultancy voor trickle loading mis is gegaan.
In de dc_event_log_r view op SQL Server zijn vaak ook hints te vinden. In de praktijk is het meestal een instelling die niet goed staat of een configuratiefoutje.
Mocht met deze tips niet lukken, plan dan een consult via https://go.invantive.com/book/consult. Op dit moment worden veel gebruikers en partners van Exact Online geconfronteerd met de overbelasting van het API ecosysteem en dit leidt tot veel hulpvragen. Mocht op korte termijn niet lukken via de agenda te plannen, bel dan s.v.p. om een afspraak te plannen. In een beperkt aantal tijdslots kunnen die ook in de avond plaatsvinden.
Klopt, dit is het juiste statement. Trickle loading is proven technology, maar er zijn grenzen in de correcties die gemaakt kunnen worden.
Zoals zichtbaar in de via ander kanaal uitgewisselde error:
There is no capacity remaining available for API use on partition ‘19…13’.
The remote server returned an error: (429) Too Many Requests.
Please acquire more API calls per day then the current limit of 100 calls or try again tomorrow.
is er door Exact besloten om voor een aantal administraties het maximum API calls per dag terug te brengen van 50.000 naar 100 per dag. Zelfs het activeren van trickle loading/webhooks is niet mogelijk omdat ook insert op WebhookSubscriptions meetelt bij het aantal API calls; daardoor is het goed activeren niet mogelijk.
We horen hier meer klachten over, zowel van partners als gebruikers. Het lijkt vaak niet terecht te zijn, maar het ligt buiten onze reikwijdte.
Als je een groot aantal dingen binnen haalt denk ik dat het goed is om toch trickle loading aan te zetten. Een limiet is er bij ons ooit op gezet en daarna weer afgehaald na activeren trickle loading. Het werkt zeker niet optimaal op dit moment, maar de hoeveelheid data die je van Exact Online naar binnen trekt vermindert met tot 95% volgens Exact Online.
Ik zeg: gebruik het waarbij mogelijk, bij uitzonderingen houd alles goed in de gaten en check je logs als er iets mis lijkt te gaan.
Dit is mijn ervaring tot nu toe. Hopelijk kunnen we de komende tijd allemaal naar een wat stabielere vorm van trickle loading toe werken. Er is niks zo irritant als data die niet opgehaald wordt, maar dat weet @forums vast ook wel
@mvk Na instellen van trickle loading even Exact Online inlichten; dan halen ze de rate limit er waarschijnlijk gewoon af zoals bij ons het geval was.
Op Invantive Cloud gaan we naast trickle loading bieden we onder BETA deze week een aantal sync API’s aan. Ze waren al eerder gebouwd, maar de documentatie en stabiliteit rammelt. Voor een aantal gebruikers kan dit een eenvoudiger alternatief zijn. Er komt nog een post in ‘Wiki (nl)’ channel met uitleg hoe de status van het incrementeel laden via Data Dictionary views gecontroleerd en geanalyseerd kan worden. Dat is vergelijkbaar met dc_event_log_r op Data Replicator.
Voor grote omgevingen blijft Data Replicator de aanbevolen oplossing; het is de enige oplossing van ons die gemakkelijk terabytes aan Exact, AFAS of Twinfield data verwerkt in 1 of duizenden administraties.
Ik leef ook met je mee, hier werkt het op dit moment ook niet helemaal zoals het zou moeten.
Wij gebruiken trickle loading in combinatie met
alter persistent cache force refresh approach copy
Dat betekent dat 's nachts de data al juist binnen zou moeten komen.
Volledigheidshalve wordt daarnaast overdag voor een beperkt aantal administraties de alter persistent cache force approach copy variant gebruikt.
Dit doen we elke dag met een wisselend aantal administraties waardoor door de bank genomen er nooit mutaties van langer dan een week ontbreken in onze eigen database.
M.b.t. het issue van onze huidige release zal ik een nieuw topic aanmaken.
Na analyse met @mvk bleek dat gedurende het laden de rate limits blijvend overschreden werden. Het inschakelen van WebhookSubscriptions was ook erg lastig.
Uiteindelijk verdwenen na paar weken versies die in de status Seeding bleven hangen de Ready-versies in Obsolete status. Er is een intern bugreport ITGEN-5339 om deze edge case beter te behandelen, maar dat heeft geen prioriteit.
Oplossing was om de data binnen de daglimieten te activeren. Het niet kunnen registreren van WebhookSubscriptions met daglimieten van 100 API calls per administratie is gemeld als showstopper (case 02933420). Naar verluidt zouden de rate limits op de betrokken administraties al enkele weken geleden teruggezet zijn naar 50.000, maar dit komt nog niet naar voren in de headers of werking.
Voor het accuraat meten van het daadwerkelijk gebruik kunnen de instructies gevolgd worden uit API-calls loggen in NDJSON formaat voor bijvoorbeeld Elasticsearch. Dit vereist BETA versie 20.1.365 of hoger. Hierin zitten ook verbeterde versies van de sync API’s TransactionLinesIncremental en ItemsIncremental die als vervanging dienen van TransactionLinesBulk en ItemsBulk.
De door de clientsoftware verstuurde API-calls lijken niet aan te sluiten bij de administratie door de Exact infrastructuur. Dit is nog onderwerp van onderzoek in samenwerking met Exact Support (case 02933442).
