Vannacht kregen wij een Time-out error (5x) op een Activity in Azure Data Factory bij het ophalen van data van het ExactOnlineREST.Incremental.TransactionLinesIncremental@eol endpoint.
Bij de request was een $filter=Modified ge <datetime> meegegeven die op het moment van triggeren ongeveer anderhalve dag vroeger was.
Waren er problemen omtrent dit endpoint?
Additionele info: De activity die deze tabel wilde ophalen, startte om 00:17 vannacht.
Is het mogelijk om een (geanonimiseerde) schermafdruk van de details van het verzoek in Invantive Bridge Online Monitoring toe te voegen zoals beschreven in Meer inzicht met nieuwe Bridge Online Monitoring?
De details vindt u door te klikken op het downloadverzoek welke het onderwerp van dit onderwerp representeert.
Het downloadverzoek heeft meestal een SQL-statement waarin de tabelnaam zichtbaar is.
Gelieve tenminste de volgende gegevens zichtbaar te laten van beide kolommen:
Bijvoorbeeld:
Controleer zorgvuldig dat u zich aanmeldt op de Bridge Online-website die ook gebruikt wordt vanuit Power BI en met dezelfde gebruikersnaam. U ziet alleen de verzoeken van de Invantive Cloud-gebruiker waarmee u zich aanmeldt op de website.
Er zijn vier servers in gebruik:
bridge-online.cloudapp-online.cloudbridge-online.invantive.comapp-online.invantive.comDe gebruikte server ziet u in uw script of broncode van rapportage.
Zorg ervoor dat u het verzoek eerst selecteert om de details weer te geven. Er hoort maar één verzoek zichtbaar zijn in de schermafbeelding.
Controleer ook zorgvuldig of het verzoek een pad heeft met odata4 of apps. Verzoeken met andere paden zijn over het algemeen niet relevant voor dit doel.
Daarnaast zal de Invantive Cloud-gebruiker die de foutmelding heeft op zijn e-mailadres veelal een e-mail ontvangen met een foutmelding en tips als er sprake is van een foutmelding in Power BI, Power Query, Azure Data Factory, Qlik of Tableau.
Advies is om de spam van de betrokken gebruiker te controleren op dergelijke e-mails verzonden vanaf support@invantive.com.
Merk op dat het ophalen van alleen recente mutaties op deze wijze enorm veel overhead kent, zeker bij grote administraties.
Indien u enkel de meest recente boekingen wilt ophalen en geen rekening houdt met verwijderde boekingen, dan is het gebruik van TransactionLinesBulk aan te raden omdat deze wel server-side filtering op datum kent.
Voorbeeld:
select *
from TransactionLinesBulk
where Date >= trunc(sysdateutc)
and Date < trunc(sysdateutc) + 1
0.968 seconden voor vijf administraties
Uitgevoerde API-calls:
select url
from SessionIOs@DataDictionary
where url like '%bulk/financial/Trans%'
order
by id desc
toont:
https://start.exactonline.nl/api/v1/1234567/bulk/financial/TransactionLines?$select=*&$filter=Date%20ge%20datetime'2025-10-28T00:00:00'%20and%20Date%20lt%20datetime'2025-10-29T00:00:00'
In een administratie met 1 miljoen boekingen scheelt dit naast 1 API-call ook het uitpakken, ontsleutelen, filteren, versleutelen en opslaan van circa 1 GB aan ongecomprimeerde data in het meest optimale geval.
Indien ook de cache opnieuw opgebouwd moet worden, dan bespaart het ook nog eens 1.000 API-calls bij het initieel opbouwen.
Na een re-run heeft de activity wel gelopen. Bedankt voor de ondersteuning.
Mocht dit nogmaals optreden, moet de screenshot van de Bridge Online Monitoring dan gemaakt worden met het account dat de data ontsluit of een account met hoofdgebruiker status?
Fijn dat weer doorgelopen is!
Altijd met de Invantive Cloud-gebruiker waaronder de download draait.