Itgeneor229 Geen dagcapaciteit beschikbaar

Invantive Cloud geeft de volgende melding:

itgeneor229
De database ‘xxxxx’ kon niet worden geopend.
Er is geen dagcapaciteit meer beschikbaar voor Exact Online API gebruik op Exact Online divisie ‘xxxxxx’.
Optimaliseer uw API-gebruik of neem contact op met Exact Online Support om meer API-aanroepen per dag te krijgen dan de huidige limiet van 5,000-aanroepen, of probeer het morgen opnieuw.

Het vreemde is dat de divisie die genoemd wordt in de foutmelding niet de divisie is die in de query gebruikt wordt om te filteren. Ik krijg deze error bij meerdere administraties.

Voor de genoemde divisie zijn er vandaag in het scherm Sessie I/O’s ruim 6.000 API-calls zichtbaar, waarvan een deel niet geslaagd is.

Advies is om de sessie I/O’s bijvoorbeeld naar Excel te exporteren en met een draaitabel een analyse te maken van de meestgebruikte tabellen. Op basis daarvan kan het gebruik geoptimaliseerd worden.

Een snelle blik geeft aan dat PjtTimeTransactions intensief opgevraagd wordt (ruim 3400 API-calls). Het aantal aanroepen van SystemDivisions.Count zullen in de Invantive SQL engine proberen te beperken, dat waren er 972. Aangezien de telling op SystemDivisions een telling is die ook voor andere administraties nodig kan zijn, kan dit leiden tot een foutmelding als een andere administratie benaderd wordt.

Bedankt voor de reactie. Ik ga de PjtTimeTransactions aanpassen.

Ik krijg bij een administratie die PjtTimeTransactions en SystemDivisions niet gebruikt, alsnog de API limiet error. Ik begrijp niet helemaal wat er nu mis gaat.

Ik zou graag eens een call doen (consultancy) om samen te kijken naar mijn queries om uit te zoeken waar het nu precies misgaat waardoor ik dagelijks errors krijg.

Is dat een mogelijkheid?

Een kort consult is mogelijk en kan via Calendly - Guido Leenders gepland worden.

Stuk achtergrond in aanvulling op de tips gegeven op Geleidelijke verlaging van Exact Online API-limieten leidt tot "Too many requests" en itgeneor229 foutmeldingen : een aantal Exact Online-tabellen zijn administratie-overstijgend. PjtTimeTransactions is specifiek van een administratie, maar bijvoorbeeld SystemDivisions, CustomerCooperations, Users en Me zijn, respectievelijk, systeembreed, systeembreed, klantbreed en systeembreed. Aan de rechterzijde van de poster op onderstaande URL is hier meer uitleg over te lezen. Het is beetje ongelukkig dat Exact Online API-calls op systeembrede API’s altijd bij een administratie neerslaan. Dit speelt vooral bij accountancyomgevingen. Bij het ontwerp is er mogelijk geen rekening mee gehouden dat Exact Online ooit strikte limieten zou gaan kennen. Een aantal API’s worden gelukkig buiten beschouwing gehouden bij het tellen van de API calls.

Ik ben bekend met de tips om de calls te verminderen, maar ik weet toch vrij zeker dat ik die allemaal al heb geïmplementeerd. Ik begrijp daarom ook niet waarom er zoveel calls gedaan worden op onze administratie.

De tabel PjtTimeTransactions bijvoorbeeld heeft 100.000 rijen, dus daar zouden maximaal 1.000 calls gedaan moeten worden. Hoe dit er dan meer dan 3.000 kunnen zijn is mij een raadsel.

Advies is om de tijdstippen te controleren en of die overeenstemmen met de verwachte tijdstippen. Controleer ook dat de cache-instellingen van de gebruikte database niet te laag zijn. Als die bijvoorbeeld 1 uur zijn en de uren worden volledig elke 2 uur opgehaald, dan zal dat per 2 uur leiden tot zeg 1.666 API-calls.

Als onbekend is waar de API-calls vandaan komen, dan is het advies om ook in de Power BI, Power Query, Power BI Service en Azure Data Factory een herleidbaar kenmerk mee te geven. Een korte klap is afstappen van de real-time mogelijkheden en een kopie te maken of incrementeel de gegevens te verwerken, bijvoorbeeld tot/met 2021 vastzetten en alleen de rest toevoegen.

En is het mogelijk van het consult een factuur te krijgen ipv vooraf betalen met creditcard?

Ja, dat is mogelijk. Advies is om een tijdstip uit te zoeken en dan dit tijdstip met een verzoek tot facturatie achteraf in een e-mail te sturen aan sales@invantive.com.