Sinds kort gebruik ik ExactOnlineREST.Incremental.TransactionLinesIncremental@eol via Invantive Bridge Online (OData4) in Excel/Power BI. Mijn verwachting was dat na de eerste volledige load bij iedere verversing alleen de delta wordt opgehaald en verwerkt: gewijzigde en verwijderde rijen sinds de vorige keer. Wat ik in de logging zie, wijkt daarvan af. Ik vraag me af of dit normaal gedrag is of dat er iets niet klopt.
Omgeving
Invantive Bridge Online 26.0.286
Administratie met circa 170.000 rijen voor de incremental tabel
HTTP disk cache 4 uur, Bridge response cache 15 minuten
Wat ik zie in IncrementalLoadEventLogEntries
Na de delta volgt bij vrijwel iedere verversing een reset op basis van de rijtelling: “Full reload of incremental cache … since the current cache row count … deviates too much from the calculated allowed minimum row count …”. Daarna volgt “Reconstructing. Do not reuse old data. Full reload…”.
Bij iedere verversing staat er "Timestamp moved from to " met lege waarden, en “No need to update incremental results since there was no previous version”.
Enkele keren: “Can’t find all data files for most recent download … Expecting 2 data files, found 0”.
Wat ik zie in de Sessie-I/O’s
De delta zelf lijkt goed te werken: sync/Financial/TransactionLines?$filter=Timestamp gt …L met alleen gewijzigde rijen.
Daarna volgen echter circa 170 pagina’s van de volledige tabel. Zolang de disk cache geldig is komen die uit cache, maar een verversing duurt daardoor steeds 60 à 80 seconden.
De Deleted API wordt bij iedere verversing opgevraagd vanaf Timestamp gt 0L en gt 1L, elk 4 pagina’s. Ik had verwacht dat ook deze vanaf de laatst geziene timestamp zou starten.
Opeenvolgende verversingen starten met dezelfde Timestamp gt …L-waarde. De timestamp lijkt na een delta dus niet op te schuiven, waardoor de delta steeds groter wordt.
Als de disk cache verlopen is, wordt na de delta de volledige incremental tabel opnieuw bij Exact opgehaald (circa 220 werkelijke aanroepen, ruim 3 tot 8 minuten voor alleen deze tabel).
Wat mij opvalt
Vóór de delta sluit de opgeslagen kopie exact aan op $count. Na het verwerken van de ruim 3.000 verwijderde ID’s uit de Deleted API blijven er circa 3.000 rijen minder over. Het lijkt erop dat ID’s die als verwijderd worden gemeld nog in Exact bestaan, en dat daardoor de rijtelling-controle telkens een volledige herlaadactie veroorzaakt. Maar misschien interpreteer ik dit verkeerd.
Mijn vragen
Is het normaal dat na iedere delta de complete tabel wordt gereconstrueerd?
Is het normaal dat de Deleted API steeds vanaf timestamp 0 wordt gelezen en dat de laatst geziene timestamp niet opschuift?
Klopt mijn vermoeden over de verwijderde ID’s, of is er een andere verklaring voor de afwijkende rijtelling?
Het lukt niet volledig om de mogelijk AI-gegenereerde tekst te doorgronden.
Het volledig herladen is in ieder geval geen normaal gedrag. Dit gebeurt alleen als het algoritme van mening is dat de dataset onvolledig is.
Duizenden verwijderde rijen is ook niet gangbaar.
Advies is om een screenshot toe te voegen van een dergelijk herlaad verzoek zoals hieronder beschreven.
Aanvullen informatie
Is het mogelijk om een (geanonimiseerde) schermafdruk van de details van het verzoek in Online Monitoring op Invantive Cloud toe te voegen zoals beschreven in Meer inzicht met nieuwe 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:
de titelbalk met de request ID,
de statuscode, netwerkgrootte, pad en tijdstippen in de linkerkolom,
de foutcode en foutmelding helemaal onderaan in de linkerkolom,
de gehele rechterkolom inclusief het SQL statement, tabelnaam en parameterwaardes.
Controleer zorgvuldig dat u zich aanmeldt op de Invantive Cloud-website met dezelfde gebruikersnaam als waarmee u gegevens verwerkt via bijvoorbeeld Invantive Bridge Online. U ziet alleen de verzoeken van de Invantive Cloud-gebruiker waarmee u zich aanmeldt op de website.
Controleer juiste aanvraag en details
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, apps of mcp. Verzoeken met andere paden zijn over het algemeen niet relevant voor dit doel.
Foutmelding en tips per e-mail
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.eu.
select ...
from ExactOnlineREST.Incremental.TransactionLinesIncremental@eol
where (Division = :w1 and ((([GLAccount = :w2 or [GLAccount] = :w3) or [GLOAccount] =:w4) or [GLAccount] = :w5))
Divisie: 3619926
Grootboekrekeningen: vier verschillende GUID’s
Zichtbaar resultaat: 4119 rijen.
Verwerkt: 175866 rijen vers opgehaald uit de Exact Online API, 0 beantwoord uit cache, met 181 API-aanroepen.
Duur: 230 seconden.
Geselecteerde partities: 2
Het herladen van deze cache wordt veroorzaakt door een protocolversie upgrade. De oude cache was opgebouwd conform protocolversie 7 onder release 26.0.286, terwijl de data werd opgehaald vanuit release 26.0.334.
De inwendige logging, die mogelijk ook tot uiting komt in de audit-tabellen, legt dit vast:
Found payload in unsupported HTTP disk cache format in file '/SOMEPATH/TransactionLinesIncremental/72070809c7b62ad341e7de06cb24e183.cache': protocol version 7 instead of 9, compressed True, encrypted True.
Echter, dit is eenmalig en kan niet eerder opgetreden hebben. Uit de analyse blijkt dat ook een bug optreedt bij de bepaling van de “timestamp”. Het gedrag is niet normaal noch gewenst.
Een bugfix zal hiervoor doorgevoerd worden in de aankomende release 27.0, en indien technisch enigszins mogelijk ook nog in release 26.0 opgenomen.
Er is een nieuwe release beschikbaar die dit probleem zou moeten oplossen. De benodigde wijzigingen zijn beschikbaar vanaf release 26.0.340 en in alle toekomstige BETA versies.
Deze nieuwe release is/wordt in productie genomen op Invantive Cloud.
