In Power BI krijg ik regelmatig onderstaande melding te zien bij het ophalen van data:
OLE DB or ODBC error: [DataSource.Error] OData: Request failed: The request was aborted: The connection was closed unexpectedly…!
Meestal is de echte oorzaak zichtbaar in de foutmelding. Voor andere gevallen is die meestal terug te vinden op https://bridge-online.cloud/monitoring zoals beschreven hier.
Zie je daar een duidelijker melding? Zo ja, welke?
Blijkbaar komt bij het vernieuwen ook onderstaande melding naar voren:
Bericht code: itgenfpr029
Tekst: You are out of API requests.
In een deel van de gekoppelde Freshdesk omgevingen blijkt de connector niet betrouwbaar te werken. Een oplossing/workaround hiervoor is opgenomen in de volgende versie van Invantive Cloud (einde van de week/begin volgende week) en in de volgende 20.1 BETA. Het datamodel van Freshdesk is ook bijgewerkt met een aantal nieuwe velden.
Achtergrond Freshdesk Out of API requests
Freshdesk kent historisch op API V1 een limiet van 1.000 calls per uur. Dit beschouwde Invantive SQL als een harde rate limit: bij overschrijding hoeft er niet tientallen minuten op gewacht te worden. SQL geeft daarom dan een foutmelding zodat de gebruiker een betere oplossing kan verzinnen.
De V2 API kende afhankelijk van het plan ook API call limieten per uur: 3.000 voor blossom en garden, 5.000 voor estate en forest.
De rate limits op de V2 API zijn daarna nog aangepast en voor een deel van de gebruikers omgezet naar rate limits per minuut in plaats van per uur. Een rate limit waar je maximaal een minuut op hoeft te wachten beschouwt Invantive SQL als een zachte rate limit: wacht even en ga dan verder.
Het totale aantal API calls per minuut is op Freshdesk nooit afhankelijk van de applicatie, maar wel afhankelijk van het plan: 100 voor blossom, 200 voor garden, 400 voor estate en 700 voor forest. Er wordt dus het totale API gebruik over alle API-koppelingen heen gemeten.
Bovendien heeft Freshdesk daarnaast endpoint-specifieke rate limits toegevoegd. Je mag bijvoorbeeld wel 400 calls per minuut doen op het estate plan van Freshdesk, maar hiervan mogen er maximaal 100 betrekking hebben op Tickets lijsten. Dit endpoint-specifiek deel is een voorgedefinieerde lijst van API’s.
Daarnaast heeft men de berekening van het API call gebruik aangepast. Indien embedded resources opgevraagd worden, dan tellen die mee als 2 calls extra per embedded resource. Een API call met 3 embedded resources telt dan als 1 + 3*2 = 7 API calls. Niet gedocumenteerd, maar wel feitelijk is dat de embedded resources meetellen op de endpoint-specifieke limieten. Een ticket opvragen met company, requester en stats kost dus 7 van de 100 toegestane calls in een minuut voor endpoint Tickets en 7 van de 400 overall. Dat is dus relatief ongunstig; het vergt uitnutting van de beschikbare API calls per minuut om bijvoorbeeld companies en contacts op te vragen, want die komen niet ten laste van de endpoint-specifieke limieten en kosten gemiddeld maximaal 1 call van de 400 in dit voorbeeld (2.5 promille), terwijl ze via tickets er 2 van de 100 (2%) kosten.
De tabeldefinities zijn aangepast om minder embedded resources op te vragen, afhankelijk van de tabel. Statistieken (kolommen die met stats beginnen) worden wel structureel opgenomen.
Bovendien worden nu ook de API rate limits per minuut ondersteund als een zachte limiet. Voor de generieke limiet wordt gebruik gemaakt van de slot-based rate limiter van Invantive en die wordt na het aanmelden automatisch ingeregeld op de eigenschappen van het aangeschafte Freshdesk plan. De cijfers hiervan zijn terug te vinden via de rate limiters views in DataDictionary. De endpoint-specifieke API call rate limits worden bijgehouden als partitiespecifieke slot-based rate limiters en zijn ook terug te vinden in de standaard views van Invantive SQL voor rate limiters in DataDictionary.
De daadwerkelijke API call consumptiecijfers bij het gebruik van embedded resources worden correct berekend: werd voorheen een API call op Tickets met drie embedded resources als 1 API call geteld, voortaan wordt die als 7 API calls geregistreerd voor de rate limiting.
Het aantal API verzoeken aan Freshdesk wordt automatisch vertraagd indien de slot-based rate limiters aangeven dat een van de limieten in zicht is. Mochten meerdere API-koppelingen tegelijk draaien, dan kan nog steeds een HTTP 429 (Too many requests) optreden. In dat geval wordt automatisch vertraagd met de benodigde tijd en nogmaals geprobeerd zonder dat dit tot een foutmelding leidt.
De door Freshdesk teruggegeven API consumptiecijfers zijn inzichtelijk via de nieuwe view RateLimits (Freshdesk-specifiek).