API limiet overschreden

We halen dagelijks data op vanuit Teamleader Focus. We hebben vrijwel alle mogelijke paden voor optimalisatie (incrementeel verversen, minder data ophalen, query optimalisatie) toegepast om ervoor te zorgen dat we onder de dagelijkse API-call-limieten blijven. De data die we ophalen is vrij gering. De zwaarste tabellen zouden moeten zijn:

  • ± 77.000 records V2Timetracking
  • ± 7.500 records V2Flat.ProjectParticipants
  • ± 7.000 records V2Flat.ProjectsAll

Ik zou niet verwachten dat we hiermee een API call limiet van 50,000 overschrijden bij verversing op dagelijkse basis. Klopt dit vermoeden?
Is het daarnaast mogelijk om in het monitoring portal een makkelijk overzicht te krijgen van welke taken/calls/tabellen binnen Invantive de API limieten snel opmaken?

Te verwachten grofweg bij 1x ophalen zijn dan:

  • 770 API-calls voor V2Timetracking
  • 7.000 API-calls voor V2Flat.ProjectParticipants
  • 7.000 API-calls voor V2Flat.ProjectsAll

Advies is om het gebruik van V2Flat te vermijden of gefilterd op te halen (met where clause op een veld dat in de hoofdtabel Projects zit).

De daadwerkelijke API-calls zijn op te vragen via het scherm Sessie-I/O’s. Zie ook:

Meer informatie over V2Flat is te vinden op:

Ik ben nog wat verder in de monitoring gedoken en het lijkt erop alsof bij een Power BI-refresh de V2Flat tabellen meerdere malen worden aangeroepen (zie hieronder een voorbeeld van V2Flat.ProjectParticipants).

Eenmaal met SQL statement (deze geeft volgens de monitoring ook rijen terug) en eenmaal zonder SQL statement (deze geeft geen rijen terug). Beide statements nemen bij een refresh even veel tijd in beslag.

Hoe is dit te verklaren en weegt dit mee in de API-calls en duration limieten?

Klopt het daarnaast dat ProjectParticipants een view is en deze niet vanuit cache opgehaald kan worden?

Op basis van de screenshot is niet met zekerheid te zeggen wat er daadwerkelijk gebeurt. Hiervoor zijn de details van het desbetreffende request nodig.

Maar mochten herhaaldelijk dezelfde dataset opgehaald worden door de query in Power Query, dan hoort dit mee te lopen in het gebruik. De impact hangt er van af wat de verzoeken daadwerkelijk doen. Een tweede verzoek, parallel aan het eerste, hoort bijvoorbeeld uit de responsecache beantwoord te worden en zal dus geen invloed hebben op het aantal API-calls richting Teamleader Focus. Die worden door het eerste verzoek gedaan.

De onderliggende details qua API-calls naar Teamleader Focus zijn op te vragen door via de Tijdslijn of een ander monitoringscherm door te klikken naar “Sessie-I/O’s”.

Voor losse vragen is advies om apart topic te starten. ProjectParticipants is een view met definitie:

select p.* except project_id,project_reference,project_title,project_description,project_status,project_purchase_order_number,project_starts_on,project_due_on
,      l.* prefix with 'project_'
from   Teamleader.V2.Projects l
join   Teamleader.V2.ProjectParticipantsByProjectId(l.id) p

In principe staan in V2Flat-schema uitsluitend tabellen die per rij een API-call op Teamleader Focus nodig hebben. Een project kan meerdere deelnemers hebben, maar 6907 rijen en een looptijd van 2615 seconden geven aan dat het waarschijnlijk gaat om maximaal 8.000 API-calls op Teamleader Focus, wat aansluit bij de eerder genoemde 7.000.

Deze vraag is automatisch gesloten na 1 week inactiviteit. Het laatste gegeven antwoord is gemarkeerd als oplossing.

Gelieve een nieuwe vraag te stellen via een apart topic als het probleem opnieuw optreedt. Gelieve in de nieuwe vraag een link naar dit topic op te nemen door de URL er van in de tekst te plakken.

Dit topic is 3 dagen na het laatste antwoord automatisch gesloten. Nieuwe antwoorden zijn niet meer toegestaan.